получить сигнал до того, как процесс будет убит OOM killer / cgroups

11

В нашем кластере мы ограничиваем ресурсы наших процессов, например, память ( memory.limit_in_bytes).

Я думаю, в конце концов, это также обрабатывается через OOM killer в ядре Linux (похоже, читая исходный код ).

Есть ли способ получить сигнал до того, как мой процесс будет убит? (Точно так же, как -notifyопция для SGEqsub , которая будет отправлена SIGUSR1до завершения процесса.)

Я читал /dev/mem_notify здесь, но у меня его нет - есть ли что-то еще в наши дни? Я также прочитал это, которое кажется несколько уместным.

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

В настоящее время я использую один из обходных путей - это небольшой скрипт, который часто проверяет, близок ли я (95%) к пределу, и если да, отправляет процесс a SIGUSR1. В Bash я запускаю этот скрипт в background ( cgroup-mem-limit-watcher.py &), чтобы он следил за другими процессами в той же группе и автоматически завершал работу, когда родительский процесс Bash умирал.

Альберт
источник
Я не мог найти никаких авторитетных источников, и я не мог найти способ вызвать OOM killer для конкретного процесса вручную (чтобы проверить идею) , но из того, что я обнаружил, кажется, что OOM killer просто отправляет SIGTERM, поэтому вам нужно установить обработчик для этого сигнала.
Привет, Ангел,
5
@ Привет-Ангел: Из исходного кода Linux , кажется, что он отправляет SIGKILL.
Альберт
@ Альберт После прочтения исходного кода я также думаю, что OOM Killer будет напрямую отправлять сигнал SIGKILL.
Энди

Ответы:

5

Можно зарегистрироваться для уведомления о том, когда использование памяти cgroup превышает порог. В принципе, установка порога в подходящей точке ниже фактического предела позволит вам отправить сигнал или предпринять другие действия.

Видеть:

https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt

Крис Эмерсон
источник
5

Убийца OOM посылает SIGKILL, поскольку в противном случае проблемная программа будет продолжать выбор.

Это означает, что у процесса нет абсолютно никакой возможности узнать, когда он собирается его убить.

Управление такими проблемами обычно подразумевает внесение исправлений в программы или их конфигурацию. Иногда, в зависимости от конфигурации системы, простое увеличение пространства подкачки может дать ОС больше гибкости в управлении памятью, чтобы избежать таких радикальных мер.

Джули Пеллетье
источник