Метрики, которые нужно собрать (с чем и зачем):
- Память (общая/детали): $/proc/meminfo$ — $MemTotal,MemFree,Buffers,Cached,SwapTotal,SwapFree$. Показывает общий баланс.
- Использование по процессам: $RSS,VSZ,PSS$ (PSS из smaps или smem) и число потоков. Источник: $/proc/<pid>/status$, $/proc/<pid>/smaps$. PSS нужен, чтобы корректно суммировать реально потреблённую память для всех процессов.
- Статистика страниц: $/proc/vmstat$ — $pgpgin,pgpgout,pswpin,pswpout,pgmajfault,pgfault$. Показывает обмен страницами и типы ошибок страниц.
- Временные ряды page-fault/swap: vmstat/sar (например, `vmstat 1`) — поля $si,so,bi,bo$ и $r,b$. Для мгновенной динамики.
- CPU и ожидание IO: загрузка CPU (user/system/idle) и $iowait$ (top, mpstat). При thrashing — часто низкий CPU user+system и высокий $iowait$.
- Диск: iostat или ioping — I/O throughput и latency (await, svctm). Swap интенсивно грузит диск.
- Показатели kswapd/ksm/anon_reclaim: dmesg/trace для kswapd activity, `/proc/vmstat` counters о reclaim scanning.
- Логи OOM и dmesg: наличие OOM-killer событий.
- При контейнерах: cgroup stats (memory.current, memory.swap.max, memory.events).
- Дополнительно: мониторинг приложений — GC-метрики (heap usage, GC pause), пул памяти аллокаторов (jemalloc).
Как определить причину (алгоритм):
1. Посмотреть базовую картину: если
$$\sum _i{\text{PSS}}_i>\text{MemTotal}$$ — суммарная рабочая совокупность превышает ОЗУ, значит конкурентный working set не помещается.
2. Проверить $/proc/vmstat$: если $pswpin$ и $pswpout$ большие и/или $pgmajfault$ высоки — много реальных подгрузок с диска (ключевой признак thrashing).
3. Сопоставить с CPU: если CPU idle высокий и $iowait$ тоже высокий — система простаивает, ожидая подкачки (типичный симптом).
4. Найти виновников: сортировка процессов по $PSS$, $RSS$, числу page-faults (maj/min) — через `smem`, `ps`, `top -o RES`, `pidstat -r -p ` или eBPF-скрипты, показывающие page-faults по PID.
5. Проверить дисковую подсистему: если диск уже перегружен (высокий await) — подкачка будет медленной, усиливая thrashing.
6. Уточнить природу page-faults: много minor faults (minflt) vs major faults (majflt). Для thrashing опасны именно major faults и swap activity.
7. Проверить параметры ядра и конфигурацию (swappiness, zswap, THP), OOM-события, и поведение GC у управляемых языков.
Меры для устранения/смягчения
A. На уровне ОС
- Немедленно (временно):
- Уменьшить конкуренцию: приостановить/убить низкоприоритетные процессы, снизить число параллельных задач.
- Ограничить ресурсы контейнерам/процессам через cgroups (memory.limit/memory.high) — чтобы избежать глобального thrashing.
- Настройки и возможности ядра:
- Тюнинг swappiness: например, `sysctl -w vm.swappiness=` (обычно уменьшение, например $10$ вместо $60$, чтобы уменьшить агрессивную подкачку для некоторых нагрузок).
- Включить zswap/zram для сжатия страниц в памяти: снижает I/O при частой подкачке.
- Отключить или настроить THP (transparent hugepages) для некоторых рабочих нагрузок (THP может ухудшать латентность).
- Настроить `vm.vfs_cache_pressure` и `vm.min_free_kbytes` при необходимости.
- Использовать faster swap (SSD) или выделить отдельный быстрый диск для swap.
- Архитектурные меры:
- Увеличить физическую память.
- Перераспределить рабочую нагрузку и уменьшить степень параллелизма.
- Локальные политики:
- Настроить OOM-killer или `oom_score_adj` для приоритезации процессов.
- Использовать `mlock()`/`mlockall()` для критичных процессов, если нельзя подкачивать их страницы (осторожно — может усугубить общую нехватку ОЗУ).
- Применять cgroup v2 memory controller: `memory.high` для динамического throttling и `memory.swap.max`.
B. На уровне приложений
- Уменьшить рабочую совокупность:
- Обрабатывать данные потоково, использовать стриминг и батчи вместо загрузки больших объёмов в память.
- Использовать более компактные структуры данных/сжатие.
- Управление конкурентностью:
- Ограничить число одновременно запущенных рабочих потоков/процессов, внедрить очередь задач и backpressure.
- Профилирование и оптимизация аллокаций:
- Выявить «утечки» и ненужные буферы, оптимизировать аллокаторы (переключиться на jemalloc/tcmalloc, tune arenas).
- Для управляемых сред (JVM, Go, .NET):
- Настроить heap size, GC-параметры (например, уменьшить max heap, настроить G1/conc GC), профилировать GC pauses.
- Использовать memory pools/reuse вместо частых malloc/free.
- Если возможно, использовать memory-mapped файлы осторожно (mmap) — они могут уменьшить копирования, но при частых page-in тоже приводят к подкачке.
Как подтверждать эффект:
- До/после изменений смотреть временные ряды: $pgmajfault/s$, $pswpin/pswpout$, $iowait$, CPU utilization и суммарную PSS; успешная мера снизит swap IO и page faults и увеличит полезную CPU-работу.
Краткие индикаторы thrashing:
- Высокие $pswpin/pswpout$ и $pgmajfault$.
- $\text{sum PSS}>MemTotal$.
- Низкий полезный CPU и высокий $iowait$.
- Длительная активность kswapd и высокие дисковые задержки.
Если нужно — могу дать список конкретных команд (vmstat, iostat, pidstat, smem, perf/eBPF) и пример последовательности диагностики.