Как понять, что процесс потребляет много ОЗУ в Linux

Диагностика потребления оперативной памяти процессами в Linux

Понимание того, что процесс потребляет много ОЗУ, — ключевой навык для DevOps-инженера, так как память напрямую влияет на стабильность и производительность системы. "Много" — понятие относительное: для сервера с 512 ГБ ОЗУ 10 ГБ могут быть нормой, а для инстанса с 2 ГБ — катастрофой. Поэтому анализ всегда должен быть контекстуальным.

Основные инструменты мониторинма

1. Классические утилиты командной строки

top / htop — первичные инструменты для быстрой оценки. В top смотрим колонки:

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

# Запуск top с сортировкой по потреблению памяти (внутри top нажать 'M')
top

# Более наглядная альтернатива
htop

ps — для точечных проверок и скриптов:

# Показать топ-10 процессов по потреблению RSS
ps aux --sort=-rss | head -11

# Детальная информация по конкретному процессу
ps -o pid,user,rss,vsz,cmd -p <PID>

2. Продвинутая диагностика с smem

Утилита smem показывает более корректную картину за счёт учёта разделяемой памяти:

# Установка на Ubuntu/Debian
sudo apt install smem

# Показать процессы с учётом пропорциональной (PSS) и уникальной (USS) памяти
smem -s rss -r -c "pid user pss rss vss command"

PSS (Proportional Set Size) — наиболее объективный показатель, делит разделяемую память между процессами.

3. Анализ через /proc файловую систему

Детальную информацию можно получить напрямую из ядра:

# Статистика памяти процесса с PID 1234
cat /proc/1234/status | grep -E 'VmPeak|VmSize|VmRSS|VmData|VmStk'

# Или более компактно
cat /proc/1234/statm
# Вывод:  размеры в страницах: total program size, resident, shared, text, lib, data, dirty

Что считать "много" памяти? Критерии оценки

1. Абсолютные значения: Процесс занимает >70% доступной физической памяти
2. Относительные значения: Потребление постоянно растёт (утечка памяти)
3. Системные индикаторы:
   • Высокое значение oom_score (близко к 1000)
   • Активное использование свопа (si/so в vmstat)
   • Давление памяти в vmstat или sar:

   # Показать статистику памяти
   vmstat -s
   
   # Мониторинг в реальном времени
   sar -r 1 10
   

Практический workflow диагностики

Когда система предупреждает о высокой памяти:

1. Быстрая оценка ситуации:

   free -h
   top -o %MEM
   

2. Идентификация "проблемных" процессов:

   # Используем ps с сортировкой
   ps -eo pid,ppid,cmd,%mem,%cpu,rss --sort=-%mem | head -20
   

3. Глубокий анализ конкретного процесса:

   # Детальная память
   pmap -x <PID>
   
   # Статистика памяти из /proc
   cat /proc/<PID>/smaps | awk '/Size|Rss|Pss|Shared|Private/{print}'
   

4. Проверка на утечки памяти:

   # Мониторинг изменения RSS во времени
   watch -n 5 'ps -o rss,cmd -p <PID>'
   

Особые случаи и нюансы

• Кэшированная память: Linux активно использует свободную память для кэша. Проверяйте available в free -h, а не просто free.
• Виртуальная память vs резидентная: Высокий VIRT не всегда проблема, если RSS небольшой.
• Контейнеры и cgroups: В Docker/Kubernetes смотрите лимиты cgroup:

  # Для контейнера Docker
  docker stats <container_name>
  
  # Прямой доступ к cgroup (если процесс в контейнере)
  cat /sys/fs/cgroup/memory/<cgroup_path>/memory.usage_in_bytes
  

Автоматизация мониторинга

Для production-систем полагайтесь на системы мониторинга:

• Prometheus + node_exporter с алертами по node_memory_MemAvailable
• Grafana дашборды с историей потребления памяти процессами
• Alerts на основе:
  • Длительно высокое потребление
  • Постоянный рост RSS
  • Частые oom-killer срабатывания

Ключевой принцип: "Много" памяти — это когда процесс потребляет непропорционально много ресурсов относительно своей функции, мешает работе других процессов или приближает систему к исчерпанию памяти и активации OOM-killer. Регулярный мониторинг и понимание нормального поведения ваших приложений позволит отличать реальные проблемы от штатной работы.