OOM Killer & Управление памятью
Тема дорожной карты · Linux & Unix Fundamentals
Когда ядро не может высвободить достаточно памяти, оно активирует OOM Killer, который вычисляет oom_score каждого процесса, основываясь на использовании памяти (RSS), и убивает процесс с наивысшим счётом, чтобы предотвратить крах системы. Управление кандидатами на уничтожение можно осуществлять через файл /proc/<pid>/oom_score_adj, где значение -1000 отключает процесс от OOM Killer, а +1000 делает его наиболее вероятной жертвой. В системе управления службами systemd можно задать параметр OOMScoreAdjust= для конкретных юнитов. Для отслеживания событий OOM Killer можно использовать команду dmesg -T | grep -i oom или journalctl -k. Настройки, влияющие на поведение OOM Killer, включают параметры vm.overcommit_memory, vm.swappiness и vm.panic_on_oom в конфигурации sysctl. На современных хостах рекомендуется использовать systemd-oomd, который использует PSI (Process Stats Interface) для более раннего определения проблем с памятью и опережающего действия OOM Killer.
Как это работает
OOM Killer & Управление памятью используют методологию USE (Utilisation, Saturation, Errors) и четыре золотых сигнала (latency, traffic, errors, saturation). Инструменты для мониторинга состояния системы включают top/htop/atop для анализа процессов, vmstat 1 для получения данных о состоянии CPU и памяти, iostat -x 1 для анализа работы дисков, mpstat -P ALL 1 для анализа загрузки каждого процессора, pidstat 1 для анализа I/O и CPU использования каждого процесса, free -h для анализа использования памяти и dstat для получения многомерных метрик. Для более глубокого понимания состояния системы можно использовать инструменты perf для профилирования ядра и bpftrace/bcc-tools для трассировки событий с использованием eBPF.
Когда применять
Перед тем как начать оптимизацию системы, необходимо провести профилирование, чтобы понять текущее состояние системы. Сначала используйте htop и iostat -x 1, чтобы заметить очевидные проблемы с загрузкой CPU и дисков. Если вы заметили проблемы, углубитесь в детали с помощью perf top или eBPF. Для HTTP-сервисов важно следить за upstream-метриками, такими как latency p95/p99 и error rate, так как бутылочное горлышко может быть в downstream-БД, а не в самой системе Linux. Использование Prometheus и node_exporter на каждом production-хосте с самого начала поможет эффективно мониторить и оптимизировать производительность системы.
Типичные ошибки
Типичные ошибки при использовании OOM Killer & Управление памятью включают неправильное понимание средней загрузки системы (uptime), вместо того чтобы анализировать процентили. Также часто происходит ошибка в интерпретации высокой загрузки как проблемы с CPU, когда на самом деле это может быть результатом uninterruptible-IO wait (top D-state). Еще одна распространенная ошибка — изменение настроек ядра на основе информации из блогов без тщательного понимания их влияния на систему (sysctl-бомбы). Также важно помнить, что оставленный tracing/ftrace в production может привести к снижению производительности (perf-хит). Перед любыми изменениями важно установить базовую производительность системы и измерить её после внесения изменений, чтобы определить, действительно ли они улучшают ситуацию.