Учет памяти каждого процесса сложен по ряду причин, о которых я расскажу через минуту. Для простого мониторинга вполне достаточно сценариев gkrellmd или nagios. Если вы хотите большей точности, вам нужно выглядеть сложнее.
SEMEM представляет концепцию пропорционального размера набора :
Поскольку большие части физической памяти обычно используются несколькими приложениями, стандартная мера использования памяти, известная как размер резидентного набора (RSS), значительно переоценивает использование памяти. Вместо этого PSS измеряет «справедливую долю» каждого приложения в каждой общей области, чтобы дать реалистичную оценку.
Пример: вы запускаете GNOME, вызывая запуск нескольких процессов, по одному для каждого апплета и программы. Все они связаны с libglib. Linux загружает libglib в один блок памяти и отображает его в каждом процессе, который хочет libglib. Наивный учет памяти подсчитывает полный размер libglib для каждого связанного с ним процесса.
SEMEM делит стоимость libglib между процессами, использующими его, чтобы дать более полную картину реальности. Он также имеет ряд опций для отображения использования памяти (с веб-сайта):
- Показать основную информацию о процессе смем
- Показать системное представление smem -R 4G -K / path / to / vmlinux -w
- Показать итоги и проценты smem -t -p
- Показать разные столбцы smem -c "name user pss"
- Показать процессы, отфильтрованные по отображению smem -M libxml
- Показать отображения, отфильтрованные по процессу smem -m -P [e] volution
- Чтение данных из архива SEMP для захвата --source capture.tar.gz
- Показать гистограмму с пометкой pid smem --bar pid -c "pss uss"
- Покажите круговую диаграмму RSS, помеченную именем smem --pie name -s rss
Вам, однако, понадобится совсем новое ядро (> 2.6.27).