Как измерить использование памяти приложением или процессом в Linux?
Что касается использования инструмента замера «ps». «ps» не является точным инструментом, который можно использовать для этой цели.
Почему ps «ошибается»:
В зависимости от того, как вы на это посмотрите, ps не сообщает о реальном использовании памяти процессами. На самом деле он показывает, сколько реальной памяти занимал бы каждый процесс, если бы он был единственным запущенным процессом. Конечно, на типичной машине Linux в любой момент времени запущено несколько десятков процессов, что означает, что числа VSZ и RSS, сообщаемые ps, почти наверняка неверны.
Ответ 1
С помощью ps или аналогичных инструментов вы получите только количество страниц памяти, выделенных этим процессом. Это число корректно, но:
Не отражает фактический объем памяти, используемый приложением, а только объем памяти, зарезервированный для него.
Может вводить в заблуждение, если страницы используются совместно, например, несколькими потоками или при использовании динамически подключаемых библиотек.
Если вы действительно хотите узнать, какой объем памяти на самом деле использует ваше приложение, вам нужно запустить его в профилировщике. Например, Valgrind может дать вам представление об объеме используемой памяти и, что более важно, о возможных утечках памяти в вашей программе. Инструмент профилировщика кучи в Valgrind называется «massif».
Massif — это профилировщик кучи. Он выполняет подробное профилирование кучи, делая регулярные снимки кучи программы. Он создает график, показывающий использование кучи с течением времени, включая информацию о том, какие части программы отвечают за наибольшее количество выделений памяти. График дополняется текстовым или HTML-файлом, содержащим дополнительную информацию для определения того, где выделяется больше всего памяти. Massif запускает программы примерно в 20 раз медленнее, чем обычно.
Как объясняется в документации Valgrind, вам необходимо запустить программу через Valgrind:
valgrind --tool=massif <исполняемый файл> <аргументы>.
Massif записывает дамп снимков использования памяти (например, massif.out.12345). Они предоставляют (1) временную шкалу использования памяти, (2) для каждого снимка запись о том, где в вашей программе была выделена память. Отличным графическим инструментом для анализа этих файлов является massif-visualizer. Но мне очень помог ms_print, простой текстовый инструмент, поставляемый с Valgrind.
Чтобы найти утечки памяти, используйте (по умолчанию) инструмент memcheck в valgrind.
Ответ 2
В последних версиях Linux используйте подсистему smaps. Например, для процесса с PID 1234:
cat /proc/1234/smaps
Это точно скажет вам, сколько памяти он использует в данный момент. Более того, он разделит память на частную и общую, так что вы сможете узнать, сколько памяти использует ваш экземпляр программы, не включая память, разделяемую между несколькими экземплярами программы.
Ответ 3
Используйте «smem», который является альтернативой «ps» и вычисляет USS и PSS для каждого процесса. Вам, вероятно, нужен PSS.
USS — размер уникального набора. Это количество неразделенной памяти, уникальной для данного процесса (считайте, что это U для уникальной памяти). Он не включает общую память. Таким образом, этот показатель занижает объем памяти, используемой процессом, но он полезен, когда вы хотите игнорировать общую память.
PSS — пропорциональный размер набора. Это то, что вам нужно. Он складывает уникальную память (USS) вместе с долей общей памяти, разделенной на количество процессов, разделяющих эту память. Таким образом, это даст вам точное представление о том, сколько реальной физической памяти используется на процесс — при этом общая память действительно представлена как общая. Считайте, что буква P означает физическую память.
Как это сравнивается с RSS, о котором сообщают «ps» и другие утилиты:
RSS — размер резидентного набора. Это объем разделяемой памяти плюс неразделяемая память, используемая каждым процессом. Если какие-либо процессы используют общую память, этот показатель будет завышать количество реально используемой памяти, потому что одна и та же общая память будет учитываться более одного раза — появляясь снова в каждом другом процессе, который использует ту же память. Таким образом, этот метод довольно ненадежен, особенно когда процессы с большим объемом памяти имеют много дубликатов — что часто встречается на сервере, например, в процессах Apache или PHP (FastCGI/FPM).
Обратите внимание: «smem» также может (опционально) выводить графики, такие как круговые диаграммы и тому подобное. Думаю, вам не нужно ничего из этого. Если вы просто хотите использовать его из командной строки, как вы могли бы использовать «ps» с флагом -A v, то вам не нужно устанавливать рекомендуемые зависимости для Python и Matplotlib.
Ответ 4
Это отличное резюме инструментов и проблем: ссылка archive.org
Я процитирую его, чтобы больше разработчиков действительно прочитали его.
Если вы хотите проанализировать использование памяти всей системой или тщательно проанализировать использование памяти одним приложением (не только использование кучи), используйте «exmap». Для анализа всей системы найдите процессы с наибольшим эффективным использованием, они занимают больше всего памяти, найдите процессы с наибольшим использованием на запись, они создают больше всего данных (и поэтому, возможно, имеют утечки или очень неэффективно используют данные). Выберите такое приложение и проанализируйте его для отображения результата анализа. Более подробную информацию см. в разделе «exmap». Также используйте «xrestop» для проверки высокого использования ресурсов X, особенно если процесс X-сервера занимает много памяти. Подробности см. в разделе «xrestop».
Если вы хотите обнаружить утечки, используйте valgrind или, возможно, kmtrace.
Если вы хотите проанализировать использование кучи (malloc и т. д.) приложением, запустите его в memprof или с помощью kmtrace, профилируйте приложение и найдите в дереве вызовов функций самые большие выделения памяти. Более подробную информацию смотрите в соответствующих разделах документации.
Ответ 5
Если процесс не использует слишком много памяти (либо потому, что вы ожидаете этого, либо какая-то другая команда дала такое начальное указание), и процесс может выдержать остановку на короткий промежуток времени, вы можете попробовать использовать команду gcore.
gcore <pid>
Проверьте размер сгенерированного файла ядра, чтобы получить представление о том, сколько памяти использует конкретный процесс. Это не очень хорошо работает, если процесс использует сотни мегабайт или гигабайт, так как создание ядра может занять несколько секунд или минут в зависимости от производительности ввода-вывода. Во время создания ядра процесс останавливается (или «замораживается»), чтобы предотвратить изменения памяти. Поэтому будьте осторожны.
Также убедитесь, что в точке монтирования, где создается ядро, достаточно места на диске и что система не отреагирует негативно на создание файла ядра в этом конкретном каталоге.
Linux