Посмотреть процессы прибитые OOM

PID убитого по out-of-memory процесса можно найти с помощью одной команды. Если есть логи с PID процесса, то найти пострадавшего можно, запустив ещё одну команду grep.

OOM-киллер безжалостен. Кажется, что он выбирает процесс случайным образом, который нужно пристрелить на машине. На самом деле под капотом он работает совсем по-другому, и случайности в его действиях нет. Взглянув на таблицу процессов и пару файлов, можно предсказать, какой процесс будет убит, если сейчас случится OOM.

Для поиска уже потерянного процесса эти знания бесполезны. Когда я доберусь до поиска, состояние машины уже поменяется. Как минимум в списке процессов не будет того, кого пристрелил oom-killer.

PID процесса, убитого OOM, и имя приложения можно найти с помощью одной команды. В случае с приложением на Python в выдаче будет python. Дополнительный фильтр может помочь в поисках, но слабо. Нужно заранее готовить логи к подобным разборам: добавить в них pid процесса.

dmesg -T | egrep -i 'killed process' 

Дальше дело техники. Из вывода берём подходящий по времени PID, идём в логи и ищем, что такого запускалось с этим PID. Для этого должны быть логи, а в логах — PID процесса.

Почему бывает полезно найти убитый процесс? Для веб-приложений, запускаемых под супервизором, это не принципиально: прибили один процесс, на его месте запустился новый.

Но если прибит важный долгий расчёт, который запустится повторно только через несколько часов? Если найти такой упавший расчёт, то можно предупредить пользователей, что результаты будут с опозданием. И перезапустить его, не дожидаясь следующего запуска по расписанию.

Процессы не убиваются случайным образом. Для этого используется скоринг процесса: число растёт, если процесс потребляет много памяти, и падает, если процесс живёт долго в системе. Более подробно про скоринг и работу киллера читайте в статье Taming the OOM killer на LWN.