Память нескольких worker-процессов: почему сумма RSS завышает расход

После увеличения числа обработчиков сумма RES в top превысила объём установленной памяти. При этом сервер работает, swap почти не меняется, а команда просит срочно вернуть старую конфигурацию. Сначала нужно выяснить, что именно сложили. Несколько процессов могут отображать одну физическую страницу, и обычная сумма RSS посчитает её несколько раз.

Какая цифра отвечает на вопрос о размещении

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

Пример с библиотекой объясняет расхождение без сложного профилировщика. У каждого из четырёх процессов-обработчиков есть 100 МиБ частных страниц и 80 МиБ общей библиотеки. Сумма RSS составит 720 МиБ, сумма PSS — около 480 МиБ. В реальной системе отображения и степень совместного использования меняются, поэтому измерять нужно все процессы примерно в одно время.

Снять данные с нужного процесса

ps -C worker -o pid,ppid,rss,vsz,etime,cmd
cat /proc/1234/smaps_rollup
cat /proc/1234/status

Замените 1234 выбранным PID. В smaps_rollup смотрите Rss, Pss, Private_Clean и Private_Dirty. Доступ к чужому процессу может ограничиваться настройками procfs и ptrace. Если файла rollup нет, более подробный smaps содержит показатели по отдельным отображениям. Смысл полей описан в справке smaps.

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

Измерить цену следующего процесса-обработчика

Снимите показатели при двух, затем при четырёх worker на одинаковой рабочей нагрузке. Сравнивайте установившийся режим после прогрева, отмечая число одновременно выполняемых задач. Если у приложения модель prefork, запись в ранее общие страницы может постепенно увеличивать частную память. Измерение сразу после запуска недооценит расход через час.

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

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

Продолжить диагностику

В курсе «Linux и Bash для DevOps-инженеров» работа с процессами и поиск проблем памяти связаны с сопровождением сервиса под systemd. Это следующий шаг после разового замера: научиться сопоставлять состояние приложения, системные ограничения и журнал. Откройте программу и посмотрите разделы о процессах, памяти и диагностике.

Ещё по теме

• MemoryHigh замедляет сервис: читаем memory.events до аварии
• Сервер тормозит без OOM: как проверить давление памяти через PSI