Процес раптово зник, сайт впав, а в логах — «Killed»? Найімовірніше, спрацював OOM Killer (Out Of Memory Killer) — захисний механізм ядра Linux. Коли вільна памʼять закінчується, ядро не дає системі повністю зависнути, а примусово вбиває «найненажерливіший» процес. Розберемо, як знайти, що саме впало, хто зʼїв RAM і як налаштувати сервер, щоб це не повторювалось.
OOM Killer спрацьовує при нестачі RAM і вбиває процес із найвищим oom_score (зазвичай той, що зайняв найбільше памʼяті). Шукайте сліди в dmesg/journalctl, а лікування — swap, ліміти памʼяті або більше RAM на сервері.
Що таке OOM Killer і чому він вбиває процеси
Linux дозволяє процесам резервувати більше памʼяті, ніж є фізично (overcommit). Поки всі не використовують її одночасно — все добре. Та коли реальне споживання впирається в межу і swap вичерпано, ядро мусить звільнити памʼять негайно, інакше зависне вся система. Тоді й приходить OOM Killer: він обирає процес із найбільшим «балом» (oom_score) і завершує його.
Як знайти, що саме вбили
- dmesg -T | grep -i -E 'killed process|out of memory' — покаже час і назву вбитого процесу
- journalctl -k | grep -i 'out of memory' — те саме з журналу ядра (з датами)
- Шукайте рядок виду «Out of memory: Killed process 1234 (mysqld)» — у дужках імʼя винуватця
- grep -i oom /var/log/syslog — на системах, де ядро пише в syslog
Як знайти, хто зʼїдає памʼять
- top або htop → відсортуйте за %MEM (клавіша M у top) — побачите топ споживачів
- ps aux --sort=-%mem | head — топ процесів за памʼяттю списком
- free -h — скільки RAM і swap вільно прямо зараз
- Перевірте oom_score процесу: cat /proc/<PID>/oom_score — що вищий, то ймовірніше його вбʼють
Найчастіше OOM ловлять MySQL/MariaDB з роздутим буфером, PHP-FPM під навантаженням, Node.js із витоком памʼяті та Java-застосунки без обмеження heap. Починайте розслідування з них.
Як не допустити повторення
- Додайте swap (наприклад файл на 2–4 ГБ) — буфер на піки, щоб ядро не вбивало одразу
- Обмежте памʼять сервісам: для MySQL — innodb_buffer_pool_size, для PHP-FPM — pm.max_children, для Node — --max-old-space-size
- Використайте systemd-ліміти (MemoryMax=) або cgroups, щоб один процес не зʼїв усе
- Налаштуйте моніторинг (free, моніторинг провайдера) і алерти на 80% RAM
- Якщо памʼяті стабільно не вистачає — апгрейд тарифу VPS під реальні потреби
OOM Killer — це симптом, а не хвороба. Він каже одне: памʼяті не вистачає. Рішення — або вмістити навантаження в наявну RAM (ліміти, swap), або дати більше RAM.
Редакція Tophosting
Коли потрібен більший сервер
Swap і ліміти рятують від випадкових піків, але якщо процеси регулярно впираються в стелю — це сигнал, що тариф замалий. Перенесіть проєкт на VPS із запасом RAM: Vultr, 1Gbits чи AdminVPS дають конфігурації від 2 до 16+ ГБ із погодинною оплатою, тож можна підняти памʼять рівно під навантаження, не переплачуючи.
Підсумок
OOM Killer — не баг, а захист ядра від повного зависання при нестачі памʼяті. Алгоритм простий: знайти вбитий процес у dmesg, визначити пожирача RAM через top/ps, а далі — swap, ліміти або апгрейд. Якщо памʼяті бракує постійно, придивіться до VPS із більшим обсягом — Vultr, 1Gbits чи AdminVPS із нашого рейтингу.
