В жизни каждого сисадмина бывает Out of memory, иногда в голове, но гораздо чаще на слабых серверах. Давай разберёмся с этим коварным Out of Memory (OOM) так, как будто это детективное расследование, а ты — главный следователь.
🔎 Дело об утопленном ОЗУ
Симптомы:
- Сервер вдруг начал жутко тормозить, как будто решил прикинуться Windows 95.
- Какие-то процессы загадочно исчезли.
- В логах можно увидеть строчку вроде "Out of memory: Kill process 1234 (badguy) score 999 or sacrifice child".
В худшем случае — сервер просто упал, как программист после ночи с деплойментом и не отвечает даже на консоль.
Шаг 1: По горячим следам — изучаем dmesg
Linux, как истинный сторожевой пёс, оставляет следы в логах. Сначала заглянем в dmesg — это как просматривать камеры наблюдения после ограбления:
dmesg -T | grep -i "out of memory"
или
dmesg -T | grep -i "oom"
🔹 Что тут важного?
- Найдёшь имя процесса, который сожрал больше всего памяти.
- Увидишь, кого OOM-Killer отправил в лучший мир.
- Если жертвой стал MySQL/PostgreSQL — поздравляю, ты на пороге катастрофы 😁.
Если дело на винде - то фильтруем журнал событий на Error и Critical, и внимательно вникаем. На Windows относительно просто ищется причина, поэтому дальше разбираем только Linux.
Шаг 2: Проверяем следы в логах
В Linux полезные логи бывают в:
/var/log/syslog
/var/log/messages
/var/log/kern.log
Команда для поиска:
grep -i "memory" /var/log/syslog
или
journalctl -k | grep -i "oom"
🔹 Что тут важного?
- Можно найти процессы-жертвы и того, кто их замочил.
- Можно понять, в какое время это произошло и связать с нагрузкой.
Шаг 3: Кто тут вообще жирный?
Если сервер жив, можно посмотреть, кто сейчас прожорливее всего:
ps aux --sort=-%mem | head -10
Если ты подозреваешь конкретное приложение:
pmap -x <PID> | sort -k3 -n | tail -10
или
smem -t
(если smem установлен)
🔹 Что тут важного?
- Если видишь что-то типа java, python, node с 50+% RAM — у тебя runaway memory leak!
- Если там chrome на сервере — кто-то запускал YouTube в терминале или гамает в танки в рабочее время.
Шаг 4: Настроим слежку, чтобы не попасть снова
Чтобы предотвратить OOM в будущем, можно:
- Включить ограничение памяти для процессов через systemd
- Использовать cgroups для ограничений
- Настроить earlyoom
Вывод: кто виноват и что делать
- Если проблема не в утечке, то, скорее всего, просто нужно добавить памяти на сервер и не жмотиться, либо апгрейднуть железо.
- Логи (dmesg, syslog, journalctl) — твой лучший друг.
- Мониторинг обязателен: Zabbix, Prometheus, Netdata помогут заранее поймать жрунов.
- Ограничивай ресурсы через systemd, cgroups или настройки ядра (sysctl).
Теперь ты — опытный OOM-детектив! В следующий раз, когда сервер откинется, ты уже будешь знать, что делать, вместо панического гугления.