Как мне вернуть OOM killer агрессивность?

Question 1

В прежние времена я ругал OOM-killer за чрезмерную агрессивность и завершение работы приложений, которые я использовал. Теперь, когда я периодически наблюдаю, как моя система виснет на 15 минут из-за некорректной программы и в итоге приходится делать принудительное отключение питания, потому что она не реагирует на клавиатуру, я понимаю, что в те времена все было не так уж плохо.

Как вернуть OOM-killer к его старым, кровожадным методам?

Question 2

Я бы уменьшил количество доступного пространства swap. В наши дни типичные установки пытаются выделить столько же swap, сколько есть физической памяти (а иногда и вдвое больше). Проблема в том, что когда что-то идет не так, система попадает в спираль смерти, пытаясь “переместить” данные из памяти на диск и обратно, и она делает этого так много, что не успевает реагировать на ввод пользователя.

В старые добрые времена целые процессы выгружались на диск (и обратно), поэтому требовалось много swap.

В современных системах виртуальной памяти память выгружается блоками (а не целыми процессами), поэтому можно обойтись меньшими swap. В вашем случае, было бы лучше, если бы процессы убивались, и использование меньшего swap приведёт к тому, что OOM начнет убивать процессы раньше (вместо того, чтобы система тратила чрезмерное количество времени на переноса данных на/с диска).

Question 3

Вот что сработало для меня:

echo 1 > /proc/sys/vm/oom_kill_allocating_task

Это настройка только для этого запуска. Вы можете протестировать, запустив следующее в консольной вкладке инспектора вашего браузера:

a = []; while (true) { a.push(1); }

Если вас устраивает эта настройка, вы можете сделать её стандартной для всех будущих запусков:

echo "vm.oom_kill_allocating_task=1" >> /etc/sysctl.conf

Question 4

Установите earlyoom, он доступен на GitHub и также может быть установлен через apt в дистрибутиве Ubuntu, который я использую. Это полностью настраиваемый демон, который вмешивается до того, как ситуация выходит из-под контроля, и вы можете сами определить процент свободной оперативной памяти и/или swap, который будет триггерить процесс убийства.

Question 5

Некрология, но… увеличьте vm.min_free_kbytes, так как при достижении этого уровня запускается OOM-Killer. Я полагаю, что код не изменился с момента вашего предыдущего опыта, когда OOM-Killer вызывался часто. Но количество памяти и swap изменилось относительно этого min_free_kbytes, что, возможно, давно не менялось.

Также я начал использовать systemd-oomd. Не знаю, лучше ли это или хуже, чем триггер OOM-Killer через min_free_kbytes. Я попробовал, и кажется, что он убивает весь “скоп” systemd, т.е. он завершил ssh-сессию, из которой я запускал программы, потребляющие память. Не знаю, лучше или хуже OOM-Killer с точки зрения процесса, который он убивает. Но обнаружение нехватки памяти на стороне системы systemd-oomd кажется лучше или, по крайней мере, более гибким.

Как мне вернуть OOM killer агрессивность?

Вопрос или проблема

Ответ или решение

Теория

Примеры

Применение