Linux какие процессы занимает память

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

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

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

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

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

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

Например, вот результат

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

Размер памяти приводится в килобайтах. Согласно 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», которое отображается в нижней части вывода.

Это то, что можно считать дополнительными затратами этого процесса без учёта разделяемых библиотек. Следовательно, стоимость запуска этого экземпляра 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:

Будут выведены поля

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

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

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

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

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

Источник

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

Когда дело доходит до оптимизации производительности системы Linux, физическая память является самым важным фактором. Естественно, Linux предлагает множество вариантов, чтобы контролировать использование драгоценного ресурса памяти. Различные инструменты различаются с точки зрения их детализации мониторинга (например, в рамках всей системы, на процесс, на пользователя), интерфейса (например, графический, командной строки, ncurses) или режима работы (например, интерактивный, пакетный режим).

Вот неполный перечень программ с графическим интерфейсом или командной строкой, чтобы вам было из чего выбрать, для проверки используемой и свободной памяти на платформах Линукс.

1. /proc/meminfo

Самый простой способ проверить использование оперативной памяти — через /proc/meminfo. Этот динамично обновляемый виртуальный файл, на самом деле, источник отображаемой информации для многих других, связанных с памятью, инструментами, такими как free, top и ps tools. От количество доступной/физической памяти до количества буфера, ожидаемого для записи обратно на диск, /proc/meminfo имеет всё, что вы хотите знать об использовании системной памяти. Информация о памяти процессами также доступна из /proc/

2. atop

Команда atop — это основанная на интерфейсе ncurses интерактивная система и наблюдатель процессов для терминального окружения. Он показывает динамически обновляемую краткую информацию о системных источниках (процессор, память, сеть, ввод/вывод, ядро) с цветными предупреждениями в случае высокой загрузки системы. Он также может отсортировать процессы (или пользователей) в порядке наибольшего потребления ресурсов ими, так, что системный администратор может сказать, какой процесс или пользователь ответственен за загрузку системы. Отчёты по статистике памяти включают общую/свободную память, кэшированную/буферезированную память и информацию по виртуальной памяти.

3. free

Команда free — это быстрый и простой способ получить обзор использования памяти, почерпнутые из /proc/meminfo. Она показывает снимок общей/доступной физической памяти и подкачу системы также как используемое/свободное буферное пространство в ядре.

4. GNOME System Monitor

GNOME System Monitor — это графическое приложение, которое показывают краткую историю использования системных ресурсов для центрольного процессора, памяти, места подкачки и сети. Оно также предлагает процесс наблюдения за использования процессора и памяти.

5. htop

Команда htop — это основанный на ncurses интерактивный просмотрщик процессов, который показывает использование памяти по процессам в реальном времени. Он может сообщить размер занимаемой памяти процессом в основной памяти (RSS), общий размер программы в памяти, размер библиотеки, размер общей страницы, и размер грязной страницы (в кэше) для всех запущенных процессов. Вы можете горизонтально или вертикально промотать (отсортированный) список всех процессов.

6. KDE System Monitor

В то время как рабочий стол GNOME имеет GNOME System Monitor, рабочий стол KDE имеет свой собственный аналог: KDE System Monitor. Его функциональность преимущественно схожа с версией GNOME, т. е. Показ в реальном времени историю использования системных ресурсов, также как и потребление процессора/памяти отдельными процессами.

7. memstat

Утилита memstat — это полезный для выявления какой (какие) исполняемый(ые) процесс(ы) и разделяемые библиотеки потребляют виртуальную память. Получая ID процесса, memstat выявляет как много виртуальной памяти использовано связанными с этим процессом исполнимым кодом, данными и разделяемыми библиотеками.

8. nmon

Утилита nmon — это основанный на ncurses инструмент системного бенчмарка, который мониторит центральный процессор, память, дисковый ввод/вывод, ядро, файловую систему и сетевые источники в интерактивном режиме. По использованию памяти он может показать такую информацию как общую/свободную память, место подкачки, буферизованную/кэшированную память, статистику загруженной/выгруженной виртуальной памяти, это всё в реальном времени.

Команда ps может показать использование памяти отдельными процессами в реальном времени. Отображаемая информация использования памяти включает %MEM (процент от используемой физической памяти), VSZ (общее количество используемой виртуальной памяти) и RSS (общее количество используемой физической памяти). Вы можете отсортировать список процессов, используя опцию «—sort». Например, для сортировки по убыванию RSS:

10. smem

Команда smem позволяет вам измерять использование физической памяти различными процессами и пользователями, основываясь на информации, доступной из /proc. Эта утилита использует метрику пропорционально установленного размера (PSS), для точной оценки использования процессами Linux размера эффективной памяти. Анализ использования памяти может быть экспортирован в графические диаграммы в виде столбиков и нарезанных на части кнугов.

11. top

Команда top предлагает наблюдение за запущенными процессами в реальном времени вместе с различными статистиками процессов использования ресурсов. Связанная с памятью информация включает %MEM (процент используемой памяти), VIRT (общее количество используемой виртуальной памяти), SWAP (количество подкаченной виртуальной памяти), CODE (количество физической памяти, выделенной для исполнения кода), DATA (количество физической памяти выделенной для не-исполнимых данных), RES (общее количество используемой физической памяти, CODE+DATA) и SHR (количество потенциально разделённой памяти с другими процессами). Вы можете отсортировать список процессов, основываясь на использование памяти или размере.

12. vmstat

Утилита командной строки vmstat отображает немедленную и среднюю статистику различных системных активностей, включая центральный процессор, память, прерывания и дисковый ввод/вывод. Как источник информации по памяти, эта команда показывает не только использование физической памяти (например, общей/используемой памяти и буфер/кэш памяти), но также статистику виртуальной памяти (например, память загруженных/выгруженных страниц, подгруженную/загруженную).

Источник