systemd имеет OOMScoreAdjust опция, позволяющая настроить oom-killer score запущенного процесса.
Цитата из документация systemd:
OOMScoreAdjust=Устанавливает уровень настройки для убийцы нехватки памяти для выполняемых процессов. Принимает целое число от -1000 (чтобы отключить удаление OOM для этого процесса) и 1000 (чтобы убить этот процесс из-за нехватки памяти с большой вероятностью). Видеть proc.txt для подробностей.
В своей настройке я развертываю сервер NodeJs на AWS. Помимо сервера Node, на экземпляре EC2 больше не работает (кроме мониторинга и основных процессов ОС). Существуют проверки работоспособности ELB, которые в конечном итоге должны заменить сломанные экземпляры EC2.
Тем не менее, мне интересно, считается ли хорошей практикой увеличение OOMScoreAdjust чтобы ядро предпочло убить процесс сервера Node, если есть проблемы с памятью, так как он может быть автоматически перезапущен. В systemd это могло выглядеть так:
OOMScoreAdjust=1000
Restart=always
Я должен признать, что мое понимание ограничено. В настоящее время я понимаю, что это, скорее всего, не будет иметь реального значения, и лучше оставить значения по умолчанию на месте:
Тем не менее, мне любопытно, подумал ли кто-нибудь, кто лучше разбирается в этом. Включение этого будет только одной строкой в сценарии systemd. А если есть сомнения, я бы предпочел, чтобы ядро убивало процесс Node, чем какую-либо случайную системную службу.
В случае сервера с одним процессом это, вероятно, не будет иметь большого значения, но это может действительно проявить себя, если у вас есть процесс, который часто пропускает память.
Например, на настольном компьютере Firefox имеет тенденцию использовать все больше и больше памяти до тех пор, пока не будет вызван OOM-killer, и он неизменно решит, что Xorg использует больше всего памяти, и убьет его, разрушив весь ваш рабочий стол, когда на самом деле это был только браузер. это нужно было перезапустить.
Таким образом, в этом случае установка у дырявой программы оценки OOM 1000 и немедленного перезапуска не будет проблемой, потому что она будет убита первой, а когда она перезагрузится, она не будет использовать столько памяти, как раньше, освобождая память в целом.
Если процесс имеет довольно постоянное использование памяти, то это вряд ли имеет значение (но, безусловно, не повредит), но если он протекает, это, скорее всего, приведет к более быстрому восстановлению, чем если AWS ELB заметит проблему и создаст новую виртуальную машину.