Ответ
Резидентный набор памяти (Resident Set Size, RSS) — это метрика, показывающая, сколько физической памяти (RAM) в данный момент занимает процесс и которая не выгружена в swap. Это ключевой показатель для мониторинга потребления памяти.
Что входит в RSS:
- Код исполняемого файла.
- Стек и куча (heap) процесса.
- Данные (глобальные и статические переменные).
- Часть разделяемых библиотек, загруженных в память для этого процесса.
Как посмотреть RSS:
# Показать RSS для конкретного процесса (в килобайтах)
ps -o pid,rss,comm -p <PID>
# Показать топ процессов по потреблению памяти
ps aux --sort=-rss | head -10
# Более точная информация с помощью smem (показывает USS, PSS, RSS)
smem -p -k -c "pid rss uss pss command" | grep <process_name>Важные нюансы для DevOps:
- RSS может вводить в заблуждение: Поскольку разделяемые библиотеки (например,
libc.so) учитываются в RSS каждого использующего их процесса, общая сумма RSS по системе будет завышена. Для более точной оценки используется PSS (Proportional Set Size), которая делит память общих библиотек между процессами. - Мониторинг: При настройке алертинга (например, в Prometheus через node_exporter) часто смотрят на RSS, но для контейнеризованных сред лучше использовать
container_memory_working_set_bytesиз cAdvisor, который ближе к реальному давлению на память.
Ответ 18+ 🔞
Блин, смотри, вот эта вся тема с памятью — это же классика, ёпта. Все эти метрики, а на деле нихера не понятно, где правда. Так вот, есть такая штука — Resident Set Size, или просто RSS. Если по-простому, это сколько оперативки твой процесс сейчас реально жрёт, и эта память не сбежала в своп, где ей и место, собственно.
Что туда входит, спросишь? Ну, слушай:
- Сам код программы, которую ты запустил.
- Стек да куча (это где твои переменные болтаются).
- Данные всякие — глобальные, статические, ну ты понял.
- И кусочки общих библиотек, которые процесс прихватил себе.
Как на это посмотреть, если подозрение ёбать чувствую, что что-то жрёт слишком много:
# Глянуть на конкретный процесс (в килобайтах, обычно)
ps -o pid,rss,comm -p <PID>
# Или найти главных обжор в системе
ps aux --sort=-rss | head -10
# А вот smem — это уже серьёзно, там и RSS, и более честные метрики
smem -p -k -c "pid rss uss pss command" | grep <process_name>А теперь, чувак, самое важное, чтобы ты не обделался с мониторингом:
- RSS — та ещё хитрая жопа. Она может дико врать! Потому что если у тебя двадцать процессов используют одну и ту же библиотеку
libc.so, то RSS каждого из них посчитает её память как свою собственную. В итоге складываешь всё — получаешь овердохуища, а по факту памяти меньше занято. Для таких случаев есть PSS (Proportional Set Size), которая делит общую память по справедливости. - С мониторингом тоже не всё просто. Да, в том же node_exporter для Prometheus часто тащат RSS. Но если у тебя всё в контейнерах, то это как мерять температуру асфальта, чтобы понять, жарко ли в комнате. Лучше смотреть на
container_memory_working_set_bytesиз cAdvisor — это куда ближе к реальному давлению на память, которое создаёт твой сервис. Иначе алерты будут срабатывать просто так, доверия ебать ноль к таким данным.