Как предотвратить процесс от остановки?

Вы не можете запретить root уничтожать процесс. Или в этом отношении: вы не можете запретить серверу убивать процесс, который пожирает все ваши ресурсы.

То, что вы можете сделать, это разветвить команду, чтобы она перезапускалась после смерти.

Пример использования кода:

• https://stackoverflow.com/a/6538718/2920227

Я понимаю, что это старый вопрос, но поскольку оба ответа игнорируют очевидное - или, в лучшем случае, касаются поверхности - я почувствовал побуждение написать свой собственный. Учитывая формулировку вопроса, первое, что пришло мне в голову, было "убийца OOM!". В одном из других ответов даже содержится утверждение, что "что-то убивается не автоматически", что абсурдно с точки зрения пользователя. Что такое убийца OOM, если не автоматизм?

ОЫЙ убийца ваш главным враг для сценариев, как описанные, как связанная статья покажет.

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

Ваш вопрос в разбивке:

Есть ли способ предотвратить завершение процесса несмотря ни на что?

Нет, к счастью, нет. Например, ядро ​​уничтожит неправильно работающие процессы (например, отправив SIGSEGV). Это также применимо, если ваша задача работает неправильно из-за ограничения ресурсов (см. Limits.conf, getrlimit / setrlimit). То есть, если что-то внутри вашего rake задача (которая, по всей вероятности, будет использовать другие процессы для выполнения некоторой работы) разыменовывает нулевой указатель, вам все равно не повезло, и эта часть выйдет из строя, что впоследствии может привести к сбою задачи.

Root также, по всей вероятности, сможет посылать сигналы вашему процессу. И даже если вам каким- то образом удалось защитить свой процесс от всего, что связано с пользовательским пространством, root по-прежнему сможет загрузить модуль ядра и подорвать усилия ядра (возможно, за исключением активной блокировки ядра).

Я знаю о nice но я не уверен, что даю такую ​​задачу, как длительная работа с интенсивным использованием памяти rake задача с наивысшим приоритетом предотвратит ее завершение: [...]

Это не предотвратит этого, но будет использоваться как одна из нескольких эвристик для убийцы OOM. Так что да, на самом деле niceзначение будет помогать... немного. LWN статья, которую я уже связан выше, дает следующие эвристики:

• если задача имеет значение nice выше нуля, ее оценка удваивается
• Для задач суперпользователя или прямого доступа к оборудованию (CAP_SYS_ADMIN, CAP_SYS_RESOURCE или CAP_SYS_RAWIO) их оценка делится на 4. Это кумулятивно, то есть задача суперпользователя с доступом к оборудованию будет иметь оценку, разделенную на 16.
• если условие OOM произошло в одном процессоре и проверенная задача не принадлежит этому набору, его оценка делится на 8.
• итоговая оценка умножается на два в степени oom_adj (т.е. баллы <<= oom_adj, если он положительный, и баллы >>= -(oom_adj) в противном случае)

Помимо niceЗначение, которое вы также можете пойти дальше, либо работает это как корень (или с заданными возможностями), или, если вы находитесь root, вы можете быть уверены, что ваш процесс не будет убит OOM-убийцей, создав cgroup (в статье есть все подробности):

1. mount -t cgroup -o oom oom /mnt/oom-killer
2. mkdir /mnt/oom-killer/invincibles
3. echo 0 > /mnt/oom-killer/invincibles/oom.priority
4. echo <pid> > /mnt/oom-killer/invincibles/tasks, где <pid> это идентификатор процесса вашего рейк-задания...

Итак, поехали. Вы можете освободить определенные группы процессов от гнева убийцы OOM.

Однако я не уверен, что этот метод кувалды - лучший способ сделать это в первую очередь. Я думаю, тебе следует начать с oom_adjчтобы увидеть, помогает ли это вашему процессу выдержать конкуренцию с другими процессами. Особенно, если это сервер, общая услуга может быть более важной, чем конкретная задача, которая может даже не быть жизненно важной для услуги. Так что используйте с осторожностью. Вдобавок вы можете захотеть следить за расходом памяти (sysstat и друзья должны помочь). Если вы сделаете это через базу данных временных рядов и построите графики, вы даже можете заметить утечки памяти.

Если ничего из этого не работает, вам следует перейти на сайт Брендана Грегга и начать измерять различные показатели эффективности; также посмотри, сможешь ли ты взять одну из его книг. Например, возможно, у вас есть что-то вроде неуправляемой ситуации в отношении распределения памяти внутри вашего rakeзадача. Потому что вы делаете упор на длительную работу и интенсивное использование памяти, но это не обязательно связано. BPF и друзья позволят вам получить информацию, которую вы иначе не получите.