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

Как в Linux узнать, какой процесс использует всю оперативную память (RAM)?

Если в операционной системе заканчивается свободная оперативная память, то это очень сильно влияет на её производительность. Система начинает работать заметно медленнее, уменьшается её «отзывчивость», происходит более долгое переключение между окнами, новые процессы не запускаются или запускаются очень медленно. По этой причине, если какой-то процесс расходует слишком много оперативной памяти или тем более всю свободную оперативную память, не оставляя ресурсов для остальной системы, то необходимо его выявить и принять меры для оптимизации.

Как узнать, сколько свободной памяти в Linux

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

Вы увидите примерно следующее:

В этой табличке означает:

• Mem — физическая оперативная память
• Swap — раздел подкачки (если недостаёт оперативной памяти, то система сбрасывает временно неиспользуемые данные на физический диск, а потом по мере необходимости вновь загружает их в оперативную память. С одной стороны, это позволяет продолжить работу в условиях нехватки оперативной памяти, но с другой — система начинает работать заметно медленнее, поскольку физический диск всегда медленнее ОЗУ, плюс нужно время для записи на диск и считывание с диска)
• total — общее количество
• used — используемая в данный момент память (вычисляется как total — free — buffers — cache)
• free — неиспользуемая память
• shared — память, используемая (преимущественно) в tmpfs
• buff — память, используемая буферами ядра
• cache — память, используемая страницами cache и slabs
• buff/cache — сумма буферов и кэша
• available — примерное количество оперативной памяти, доступное для запуска новых приложений без использования ими раздела подкачки. В отличие от поля free, это поле принимает в расчёт страницу cache и также то, что не вся рекуперируемая (пригодная для повторного использования) память будет возвращена для рекуперации из-за того, что элементы используются в данный момент

Итак, если значение поля free, а в особенности поля available очень мало или равно нулю, значит нужно принимать меры, иначе рабочая станция или сервер будут работать крайне медленно либо могут полностью зависнуть.

Как просмотреть, какая программа потребляет больше всего оперативной памяти в top

Очень подробно о команде top, в том числе подсказки и интересные трюки описаны в статье «Как пользоваться командой top для наблюдения за процессами в Linux» — крайне рекомендуется ознакомиться.

Запуск программы top:

По умолчанию программа top сортирует процессы по их нагрузке на центральный процессор. Чтобы посмотреть, по какому полю выполняется сортировка, нажмите клавишу x:

По умолчанию в top отображаются следующие виды памяти:

• VIRT — общее количество используемой задачей виртуальной памяти, включает все коды, данные, совместные библиотеки, плюс страницы, которые были перенесены в раздел подкачки, и страницы, которые были размечены, но не используются
• RES — используемая оперативная память, является подмножеством VIRT, представляет физическую память, не помещённую в раздел подкачки, которую в текущий момент использует задача. Также является суммой полей RSan, RSfd и Rssh.
• SHR — размер совместной памяти, подмножество используемой памяти RES, которая может использоваться другими процессами
• %MEM — доля задачи в использовании памяти (RES)

Для переключения между полями сортировки, используйте . Обратите внимание, что это не курсорные клавиши, а разновидность скобок, для их использования переключитесь на английскую раскладку клавиатуры и нажимайте эти кнопки с зажатой клавишей Shift.

Пример сортировки по %MEM:

Сортировка по VIRT:

Как найти программы, которые используют больше всего памяти в ps

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

Самые «прожорливые» процессы будут внизу:

Первый столбец — это PID процесса, затем идёт виртуальная память процесса в килобайтах, затем название программы.

Ещё одна элегантная команда с использованием ps:

Она покажет что-то вроде:

Невозможно найти, через какой процесс утекает оперативная память — сумма памяти процессов меньше общей используемой памяти

В некоторых версиях ядер Linux присутствовала проблема утечки памяти на уровне ядра, поэтому нет никакой возможности обнаружить её инструментами пользовательского пространства. Пример такого ядра — 3.13.

Причём некоторые ядра допускают утечку памяти только в определённых условиях (пример: Linux Mint 17 при использовании btrfs).

Самым лучшим вариантом в этом случае является обновление ядра и системы в целом до новой версии.

Источник

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

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

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

Источник