KERNEL_MEM_LEAK Linux / DevOps

Диагностика утечек оперативной памяти в Linux: /proc/meminfo, slabtop и smem

Обновлено: 21.08.2026

Параметр MemAvailable в /proc/meminfo монотонно уменьшается без роста активности пользователей.
Высокое потребление памяти структурами ядра (SUnreclaim или SReclaimable в гигабайтах).
Утилиты ps/top показывают искаженные значения RSS из-за разделяемых библиотек.
Периодические срабатывания Out-of-Memory (OOM) Killer.

1. Экспресс-анализ /proc/meminfo

cat /proc/meminfo | grep -E "MemTotal|MemFree|MemAvailable|Active|Inactive|Slab|SReclaimable|SUnreclaim|AnonPages"

2. Анализ кэшей ядра через slabtop

slabtop -o -s c | head -n 25

Если dentry или inode_cache переполнены, сбросьте кэши файловой системы:

sync; echo 2 > /proc/sys/vm/drop_caches

3. Точный расчет потребления User Space с помощью smem

apt-get install -y smem || dnf install -y smem
smem -t -k -s pss -r | head -n 20

4. Детальный аудит конкретного процесса

PID=12345
cat /proc/$PID/smaps_rollup

Практический опыт инженера: Если память «пропадает», а smem не показывает виновника в User Space, всегда проверяйте параметр SUnreclaim в slabtop — это классический признак утечки буферов ядра sk_buff или модулей сторонних драйверов.

Частые вопросы (FAQ)

В чем разница между RSS и PSS?

RSS суммирует весь разделяемый код для каждого процесса, что приводит к завышению реального объема. PSS делит размер разделяемых страниц на количество использующих их процессов, показывая истинное потребление RAM.

Как ограничить чрезмерное разрастание Slab кэша?

Увеличьте значение vfs_cache_pressure через sysctl: vm.vfs_cache_pressure = 150 в /etc/sysctl.d/99-sysctl.conf.