Измерение памяти процесса в Linux: виртуальный размер, RSS, PSS и смысл каждого показателя

Цель

Ответить на вопрос «сколько памяти использует этот процесс» показателем, соответствующим задаче: поместится ли он на этой машине, есть ли утечка или сколько памяти он добавляет к уже работающим процессам.

Предварительные условия

Linux с правом чтения /proc/PID. Термины из справочных страниц: VmSize — размер виртуальной памяти, а VmPeak — его пиковое значение; VmRSS — размер резидентного набора, сумма RssAnon (анонимной памяти), RssFile (резидентных файловых отображений) и RssShmem (разделяемой памяти); VmHWM — пиковый размер резидентного набора; VmSwap — анонимная память, выгруженная в swap. Справочная страница помечает значения RSS, VmHWM и VmSwap как неточные и отсылает к /proc/PID/statm. В /proc/PID/smaps для каждого отображения указаны Rss и Pss — пропорциональная доля отображения, приходящаяся на процесс: общие страницы делятся между использующими их процессами. Документация ядра описывает smaps_rollup как те же поля, что и в smaps, но со значениями, суммированными по всем отображениям процесса; их можно получить из smaps, однако со значительно большими затратами.

Порядок действий

1. Прочитайте /proc/PID/status и запишите VmSize, VmRSS, RssAnon, RssFile, RssShmem, VmHWM и VmSwap вместе с отметкой времени.
2. Не решайте по VmSize, хватит ли памяти. Он учитывает зарезервированное адресное пространство — отображённые файлы, стеки потоков, арены аллокатора, зарезервированную кучу среды выполнения, — к которому процесс может никогда не обратиться. Гигабайты виртуальной памяти при умеренном RSS — нормальное явление.
3. Для вопроса «поместится ли»: рассматривайте RssAnon + VmSwap как собственные затраты процесса на анонимную память, RssShmem — как память, остающуюся выделенной, пока её удерживает хотя бы один совместный пользователь, а RssFile — как страничный кэш, который ядро может отбросить и загрузить заново.
4. Для вопроса «сколько добавляет» при множестве процессов с общими библиотеками или родительским процессом с копированием при записи: суммируйте Pss из /proc/PID/smaps_rollup. Суммирование VmRSS по процессам учитывает каждую общую страницу по одному разу на процесс.
5. Для вопроса «есть ли утечка»: измеряйте RssAnon и VmHWM через постоянные интервалы при неизменной нагрузке. Рост, который не выходит на плато, указывает на утечку либо на аллокатор, удерживающий освобождённую память; плато соответствует рабочему набору.
6. Запишите PID, командную строку, версию ядра, приложенную нагрузку и показатели, чтобы повторный запуск можно было сравнить с первым.

Ожидаемый результат

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

Ограничения и основания метода

Аллокаторы удерживают освобождённую память, поэтому RSS завышает объём живых объектов; статистика кучи на уровне языка — tracemalloc или профиль кучи среды выполнения — измеряет другое и напрямую несопоставима с RSS. Отображённые файлы и огромные страницы усложняют разделение. В контейнере cgroup учитывает больше, чем RSS процесса; см. открытый вопрос о метриках памяти контейнера. Метод основан на указанных справочных страницах; результатов измерений здесь не заявлено.