Linux размер памяти процесса

Как правильно посмотреть сколько оперативной памяти потребляет процесс

В этой заметке мы узнаем, какое значение памяти, используемой процессом, является верным.

Понимание использования памяти в Linux

Эта запись для тех людей, которые когда-либо задавались вопросом: «Почему простой текстовый редактор KDE занимает 25 мегабайт памяти?» Многие люди думают, что многие приложения Linux, особенно программы KDE или Gnome, «раздуты» исключительно на основании того, что сообщают такие инструменты, как ps. Хотя это может быть правдой, а может и нет, в зависимости от программы, в целом это не так — многие программы намного эффективнее с точки зрения памяти, чем кажется.

Что сообщает ps

Инструмент ps может выводить различную информацию о процессе, такую как его идентификатор процесса, текущее состояние выполнения и использование ресурсов. Двумя возможными выходами являются VSZ и RSS, которые обозначают «virtual set size» и «resident set size», которые обычно используются компьютерщиками по всему миру, чтобы увидеть, сколько памяти занимают процессы.

для программы Writer из офисного пакета LibreOffice на моем компьютере:

PID VSZ RSS 450151 12769740 492460

Размер памяти приводится в килобайтах. Согласно ps, Writer имеет виртуальный размер около 12 гигабайт (!) и резидентный размер около 500 мегабайт (оба числа выше указаны в килобайтах). При этом в офисном пакете открыт не очень большой файл, в котором я в данный момент пишу. Похоже, что большинству людей нравится случайным образом выбирать одно из этих числе и использовать его как реальное использование памяти процессом. Я не собираюсь сейчас объяснять разницу между VSZ и RSS, но, разумеется, это неправильный подход; ни одно из чисел не даёт точного представления о том, какова стоимость памяти для работы Writer.

Почему ps «неправильный»

В зависимости от того, как вы на это смотрите, ps не сообщает о реальном использовании памяти процессами. На самом деле он показывает, сколько реальной памяти занял бы каждый процесс, если бы он был единственным запущенным процессом. Конечно, на типичной Linux-машине в любой момент времени выполняется несколько десятков процессов, а это означает, что числа VSZ и RSS, сообщаемые ps, почти определённо «неправильны». Чтобы понять почему, необходимо узнать, как Linux обрабатывает разделяемые библиотеки в программах.

Большинство основных программ в Linux используют общие библиотеки для облегчения определённых функций. Например, программа редактирования текста поставляемых с окружением рабочего стола KDE будет использовать несколько общих библиотек KDE (для обеспечения взаимодействия с другими компонентами KDE), несколько X-библиотек (для отображения изображений, копирования и вставки) и несколько общих системных библиотек (для выполнения основных операций). Многие из этих разделяемых библиотек, особенно часто используемые, такие как libc, используются многими программами, работающими в системе Linux. Благодаря этому совместному использованию Linux может использовать отличный трюк: он загружает одну копию разделяемых библиотек в память и использует эту копию для каждой программы, которая на неё ссылается.

Хорошо это или плохо, но многие инструменты не особо заботятся об этом очень распространённом приёме; они просто сообщают, сколько памяти использует процесс, независимо от того, используется ли эта память совместно с другими процессами. Таким образом, две программы могут использовать большую разделяемую библиотеку, но при этом её размер учитывается в обоих общих показателях использования памяти; библиотека подсчитывается дважды, что может ввести в заблуждение, если вы не знаете, что происходит.

К сожалению, нелегко получить идеальное представление об использовании памяти процессом. Вам нужно не только понять, как на самом деле работает система, но и решить, как вы хотите решать некоторые сложные вопросы. Следует ли учитывать общую библиотеку, которая требуется только для одного процесса, в использовании памяти этим процессом? Если общая библиотека используется моими несколькими процессами, следует ли равномерно распределять её использование памяти между различными процессами или просто игнорировать? Здесь нет жёсткого правила; у вас могут быть разные ответы в зависимости от ситуации, с которой вы столкнулись. Легко понять, почему ps не старается изо всех сил сообщать «правильные» итоги использования памяти, учитывая неоднозначность.

Просмотр карты памяти процесса

Хватит разговоров; давайте посмотрим, как обстоят дела с этим «огромным» процессом Writer. Чтобы увидеть, как выглядит память Writer, воспользуемся программой pmap (с флагом -d после которого идёт PID (идентификатор процесса)):

Я вырезал много вывода; остальное похоже на то, что показано. Даже без полного вывода мы можем увидеть некоторые очень интересные вещи. Важно отметить, что в выводе каждая разделяемая библиотека указана дважды; один раз для сегмента кода и один раз для сегмента данных. Сегменты кода имеют режим «r-x—», в то время как данные установлены на «rw—». Столбцы Kbytes, Mode и Mapping — единственные, о которых мы будем заботиться, так как остальные не важны для обсуждения.

Если вы просмотрите вывод, вы обнаружите, что строки с наибольшим количеством килобайт обычно являются сегментами кода включённых разделяемых библиотек (те, которые начинаются с «lib», являются разделяемыми библиотеками). Что замечательно в этом, так это то, что они могут быть разделены между процессами. Если вы вычлените все части, которые совместно используются процессами, вы получите общее количество «writeable/private», которое отображается в нижней части вывода.

mapped: 12769744K writeable/private: 1037844K shared: 278856K

Это то, что можно считать дополнительными затратами этого процесса без учёта разделяемых библиотек. Следовательно, стоимость запуска этого экземпляра Writer (при условии, что все общие библиотеки уже загружены) составляет около 1 гигабайта. Это совсем другая история по сравнению с 12 гигабайтами, о которых сообщила ps.

Что все это значит?

Мораль этой истории заключается в том, что использование памяти процессами в Linux — сложный вопрос; вы не можете просто запустить ps и знать, что происходит. Это особенно верно, когда вы имеете дело с программами, которые создают множество идентичных дочерних процессов, например Apache. ps может сообщить, что каждый процесс Apache использует 10 мегабайт памяти, в то время как на самом деле предельная стоимость каждого процесса Apache составляет 1 мегабайт памяти. Эта информация становится критически важной при настройке параметра Apache MaxClients, который определяет, сколько одновременных запросов может обрабатывать ваш сервер.

Это также показывает, что стоит как можно больше придерживаться программного обеспечения для одного рабочего стола. Если вы запускаете KDE для своего рабочего стола, но в основном используете приложения Gnome, вы платите большую цену за множество избыточных (но разных) разделяемых библиотек. Придерживаясь только приложений KDE или Gnome, насколько это возможно, вы сокращаете общее использование памяти за счёт снижения предельных затрат памяти при запуске новых приложений KDE или Gnome, что позволяет Linux использовать больше памяти для других интересных вещей (например, файловый кэш, который значительно ускоряет доступ к файлам).

Так как тогда посчитать, сколько реально памяти занимает процесс в Linux?

С помощью ps или аналогичных инструментов вы получите только количество страниц памяти, выделенных этим процессом. Это правильный номер, но:

• не отражает фактический объем памяти, используемый приложением, а только объем памяти, зарезервированной для него
• может вводить в заблуждение, если страницы используются совместно, например, несколькими потоками или с помощью динамически подключаемых библиотек.

В выводе программ обращайте внимание на поля RSS и RES.

RES — используемая оперативная память, является подмножеством VIRT, представляет физическую память, не помещённую в раздел подкачки, которую в текущий момент использует задача.

RSS — это «resident set size» — физическая память без подкачки, которую использовала задача (в килобайтах). Псевдоним rssize, rsz.

Для просмотра фактически используемой памяти попробуйте команду pmap:

Address Kbytes RSS Dirty Mode Mapping

Обратите внимание на нижнюю строку начинающуюся с «total kB», это поле RSS.

В команде top ищите поле RES — вы можете сделать сортировку по данному полю, как это показано на скриншоте ниже:

Виртуальная память в Linux не складывается?

Я смотрел системный монитор в Linux и заметил, что Firefox использует 441 МБ памяти, а несколько других приложений используют 274, 257, 232 и т. д. (Добавляя до 3 ГБ виртуальной памяти). Итак, я перехожу на вкладку «Ресурсы», и там говорится, что я использую 462 МБ памяти и не раздел подкачки не задействован. Я в замешательстве. Что означает объем виртуальной памяти, если программы на самом деле её не используют. Я подумал, может быть, память они запросили, но не используют, но как ОС узнает об этом? Я не могу придумать ни одной функции «при котором данным процессам может понадобиться такое огромное количество памяти в будущем».

Во-первых, разделяемая память не совсем правильно подсчитывается методом команды top. Во-вторых, да, программа запрашивает права на память, а затем использует её, но она может никогда не коснуться выделенной ей памяти, и ОС это знает. Нет проблем если между всеми приложениями будет поделена вся доступная память вместе с разделом подкачки, по крайней мере до тех пор, пока они не пытаются всё это использовать.

Связанные статьи:

Источник

Как узнать потребление памяти процессом в Linux

В Linux потребление памяти процессами измеряется двумя значениями, VSZ и RSS (обе измеряются в байтах).

RSS — переводится как постоянное потребление памяти (Resident Set Size) и показывает сколько в момент вывода команды занято в оперативной памяти.
Также стоит отметить что он показывает весь стёк физически выделенной памяти.

VSZ — виртуальная память (Virtual Memory Size)

Посмотреть список процессов с сортировкой по этим параметрам можно командой:

Для RSS (Resident Set Size):

Для VSZ (Virtual Memory Size):

В зависимости от запущенной команды, результаты вывода будут отображаться в приоритете по занимаему месту процессом в оперативной памяти (RSS)
или количеству занимаемого места в виртуальной памяти (VSZ) в порядке убывания.

$ ps -aux --sort -rss USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND user 30799 51.2 8.1 2733764 285136 ? Rl 09:25 5:30 /usr/lib/chromium-browser/chromium-browser --ppapi-flash-path=/usr/lib/pepperflashplugin-nonfree/libpepflashplayer.so --ppap user 2800 0.1 6.6 9972812 234184 ? Sl окт31 1:26 /usr/bin/plasmashell --shut-up user 31308 2.4 5.3 1767496 188672 ? Sl 09:26 0:13 /usr/lib/chromium-browser/chromium-browser --type=renderer --enable-pinch --field-trial-handle=7228759356551874141,180166971 user 31011 3.9 5.3 1793296 186812 ? Sl 09:25 0:25 /usr/lib/chromium-browser/chromium-browser --type=renderer --enable-pinch --field-trial-handle=7228759356551874141,180166971 user 31369 5.5 4.8 1378568 171328 ? Sl 09:28 0:23 /usr/lib/libreoffice/program/soffice.bin --writer --splash-pipe=5 user 14442 12.1 4.2 1050808 150148 ? Sl 01:19 60:04 /usr/lib/x86_64-linux-gnu/libexec/kscreenlocker_greet --graceTime 5000 --ksldfd 26 user 31111 0.9 3.8 1708496 134564 ? Sl 09:25 0:06 /usr/lib/chromium-browser/chromium-browser --type=renderer --enable-pinch --field-trial-handle=7228759356551874141,180166971 user 1225 0.0 3.7 3639148 132092 ? Sl окт31 1:00 /usr/bin/plasmashell --shut-up user 31078 0.6 3.7 1724480 130724 ? Sl 09:25 0:03 /usr/lib/chromium-browser/chromium-browser --type=renderer --enable-pinch --field-trial-handle=7228759356551874141,180166971 user 30986 0.7 3.3 1717860 117660 ? Sl 09:25 0:04 /usr/lib/chromium-browser/chromium-browser --type=renderer --enable-pinch --field-trial-handle=7228759356551874141,180166971 user 1216 1.7 3.2 3271220 113736 ? Sl окт31 20:36 kwin_x11

Важными столбцами являются:

• USER Пользователь, от имени которого работает процесс
• PID Идентификатор процесса
• RSS Физическая память, занятая процессом
• VSZ Виртуальная память

Из примера видно, что большую часть памяти (RSS) занимают процессы браузера chromium.

Источник