На прошлой неделе мы решили добавить несколько SunOS (uname -a
знак равно SunOS bbs-sam-belair 5.10 Generic_127128-11 i86pc i386 i86pc
) машины в наш запущенный экземпляр munin. Во-первых, машины представляют собой предварительно настроенные устройства, поэтому я не хочу слишком сильно прикасаться к системе без надзора со стороны поставщика услуг.
Но добавить его в munin было довольно просто, написав небольшой сервис-сокет (если кому-то интересно, я разместил его на github: https://github.com/munin-monitoring/contrib/tree/master/tools/pypmmn)
Вчера я внедрил / адаптировал необходимые плагины для наших машин. И тут начинаются вопросы:
Во-первых, я не нашел способа определить подробные значения использования памяти. Я получаю всю память, запустив prtconf | grep Memory
, а свободная память с использованием vmstat
. Собирая плагин munin, я получаю следующий график:
Это в значительной степени неинформативно. Сравните это с плагином по умолчанию для узлов Linux, который содержит гораздо больше деталей:
Что наиболее важно, это показывает мне, сколько памяти на самом деле используется приложениями.
Итак, первый вопрос: Можно ли получить подробную информацию о памяти в SunOS с помощью системные инструменты по умолчанию (т.е. не использовать top
)?
Переходя к следующей загадке: просмотрев графики, я заметил активность в графиках "Вход / выход", даже если на графике памяти все еще есть неиспользуемая память:
При дальнейшем расследовании я выяснил, что df
сообщает, что /tmp
установлен на swap
. Пробежавшись по Интернету, я понял, что df
будет отображать swap
, но на самом деле он установлен как tmpfs
. Теперь я не знаю, объясняет ли это обмен.
Плагин munin по умолчанию для Solaris использует kstat -p -c misc -m cpu_stat
чтобы получить эти значения. Мне уже кажется странным, что здесь используется cpu_stat
модуль. Так что, может быть, я просто неверно истолковываю графики "листания"?
Второй вопрос: Указывают ли диаграммы подкачки, что части памяти выгружаются на диск? Или активность вызвана файловыми операциями в /tmp
?
Не так подробно, как ваш пример Linux, но вы можете использовать :: memstat макрос в mdb:
# echo ::memstat | mdb -k
Page Summary Pages MB %Tot
------------ ---------------- ---------------- ----
Kernel 178001 1390 69%
Anon 52748 412 21%
Exec and libs 1905 14 1%
Page cache 16115 125 6%
Free (cachelist) 6654 51 3%
Free (freelist) 1452 11 1%
Total 256875 2006
Physical 255662 1997
Ядро: память, используемая для невыгружаемых распределений ядра
Анон: анонимная память (кучи процессов, стек, отображение общей памяти и т. д.)
Exec и библиотеки: память, используемая для сопоставленных файлов, таких как исполняемые файлы и библиотеки
Кеш страницы: количество несопоставленного кеша страниц, включая данные, хранящиеся в / tmp
Бесплатно (список кеширования): количество страничного кеша в свободном списке, большая часть используется кешами файловой системы
Бесплатно (фрилист): количество реально свободной памяти
Две книги Макдугалла и Мауро о Solaris Internals (Solaris Internals, 2nd Edition и Solaris Performance and Tools) чрезвычайно полезны для понимания Solaris и того, как его наблюдать.
Первый вопрос: можно ли получить подробную информацию о памяти в SunOS с помощью системных инструментов по умолчанию (т.е. без использования top)?
Определенно возможно получить подробную статистику памяти и многое другое с помощью стандартных инструментов Solaris (в настоящее время SunOS - это только имя ядра). Помимо уже упомянутых echo ::memstat | mdb -k
, вы можете иметь статистику памяти для каждого процесса и пользователя с prstat -a
и на зону с prstat -Z
.
Ядро также предоставляет многочисленные статистические данные через интерфейс kstat (их использует munin).
Например, если вы хотите отобразить общий объем оперативной памяти, ее часть, используемую ядром, кеш ZFS (часть используемой памяти ядра) и свободную память, вы можете выполнить эту команду:
kstat -T d -p :::physmem :::pp_kernel zfs:::size :::pagesfree 1 3
Если вы хотите использовать виртуальную память, используйте swap -s
команда.
Второй вопрос: показывают ли графики подкачки, что части памяти выгружаются на диск? Или активность вызвана файловыми операциями в / tmp?
Ни один из вышеперечисленных. Такая активность не обязательно означает нехватку оперативной памяти и загрузку страниц. Напротив, ваш график показывает sr
значение остается равным 0. Это означает, что сканер страниц не работает и, следовательно, у вас установлено достаточно оперативной памяти. Активность подкачки просто связана с чтением и записью отображаемых в память файлов. Не о чем беспокоиться. Файлы, находящиеся в / tmp, присутствуют только в ОЗУ (в вашем случае), поэтому при доступе к ним не происходит подкачки.
Помните, что Solaris использует термин подкачки либо для обозначения части диска, используемой для хранения страниц памяти, выгружаемых из ОЗУ, либо для обозначения всего пространства виртуальной памяти, то есть области подкачки плюс часть ОЗУ, которая там не заблокирована.