¿Existe alguna forma de evitar que se elimine un proceso pase lo que pase? Lo sé, nicepero no estoy seguro de si darle la máxima prioridad a una tarea como una raketarea de larga duración que consume mucha memoria evitará que se elimine:
nice -n -20 rake xyz
Editar: lo más probable es que el cartel original quiera que tenga alta prioridad incluso si el servidor también tiene pocos recursos, hasta el punto de que otros procesos se eliminan primero.
Respuesta1
No se puede evitar que root mate un proceso. O, para el caso, no puedes evitar que el servidor elimine un proceso que consume todos tus recursos.
Lo que puedes hacer es bifurcar el comando para que se reinicie cuando se elimine.
Ejemplo usando código:
Respuesta2
Ahora, entiendo que esta es una vieja pregunta, pero dado que ambas respuestas ignoran lo obvio (o, en el mejor de los casos, arañan la superficie), me sentí impulsado a escribir la mía propia. Dada la redacción de la pregunta, lo primero que me vino a la mente fue "¡el asesino de OOM!". Una de las otras respuestas incluso afirma que "no es automático que algo muera", lo cual es absurdo desde la perspectiva del usuario. ¿Qué es el asesino de OOM sino un automatismo?
Elasesinoes su mayor enemigo en escenarios como el descrito, como lo mostrará el artículo vinculado.
Ahora depende de cuál sea el escenario exacto (construir una máquina, algún servidor...), pero en generalhacerQuiero que mi sistema operativo utilice los recursos de mi máquina en la medida de lo posible. Por eso los compré en primer lugar.
Tu pregunta, desglosada:
¿Existe alguna forma de evitar que se elimine un proceso pase lo que pase?
No,afortunadamenteno. Por ejemplo, el kernel eliminará los procesos que se porten mal (por ejemplo, enviandoSIGSEGV). Esto también se aplicará si su tarea se comporta mal debido a que se encuentra con límites de recursos (consultelímites.conf,getrlimit/setrlimit). Es decir, si algo dentro de su raketarea (que con toda probabilidad utilizará otros procesos para realizar algún trabajo) elimina la referencia a un puntero nulo, aún no tendrá suerte y esa parte fallará, lo que posteriormente puede hacer fallar la tarea.
Root también, con toda probabilidad, podrá enviarseñalesa su proceso. E incluso si tude alguna maneralogrado proteger su proceso de cualquier cosa relacionada con el espacio de usuario, rootaún podría cargar un módulo del kernel y socavar esos esfuerzos del kernel (quizás con la excepción de un bloqueo activo del kernel).
Lo sé,
nicepero no estoy seguro de si darle la máxima prioridad a una tarea como unaraketarea de larga duración que requiere mucha memoria evitará que se elimine: [...]
No lo impedirá, perovoluntadser utilizado comounode varias heurísticas para el asesino OOM. Así que sí, en realidad el nicevalorvoluntadayuda... un poco. Elartículo de LWNque ya vinculé arriba ofrece la siguiente heurística:
- si la tarea tienebuen valor por encima de cero, su puntuación se duplica
- acceso de superusuario o acceso directo al hardwareLas tareas (CAP_SYS_ADMIN, CAP_SYS_RESOURCE o CAP_SYS_RAWIO) tienen su puntuación dividida por 4. Esto es acumulativo, es decir, una tarea de superusuario con acceso al hardware tendría su puntuación dividida por 16.
- si la condición OOM ocurrió en unoconjunto de CPUy la tarea marcada no pertenece a ese conjunto, su puntuación se divide por 8.
- la puntuación resultante se multiplica por dos elevado a oom_adj (es decir, puntos <<= oom_adj cuando es positivo y puntos >>= -(oom_adj) en caso contrario)
Aparte del nicevalor, también puedes ir más allá ejecutando esto como root (o con las capacidades dadas) o, sison root, puede asegurarse de que su proceso no sea propenso a ser eliminado por el asesino OOM (el artículo tiene eltodos los detalles) creando un cgroup:
mount -t cgroup -o oom oom /mnt/oom-killermkdir /mnt/oom-killer/invinciblesecho 0 > /mnt/oom-killer/invincibles/oom.priorityecho <pid> > /mnt/oom-killer/invincibles/tasks, ¿dónde<pid>está el ID del proceso de su tarea de rake?
Ahí vas. Puedes hacer que ciertos grupos de procesos estén exentos de la ira del asesino de OOM.
Sin embargo, no estoy seguro de que este método de mazo sea el mejor.primerolo mejor que puedes hacer. Creo que debería empezar probando oom_adjpara ver si eso ayuda a que su proceso sobreviva a la competencia con otros procesos. Especialmente si se trata de un servidor, en generalserviciopuede ser más importante que una tarea particular que tal vez ni siquiera sea vital para el servicio. Así que utilícelo con precaución. Además, es posible que desee controlar si hay acaparamientos de memoria (sysstat y sus amigos deberían ayudar). Si lo hace a través de una base de datos de series temporales y traza los gráficos, es posible que incluso se dé cuenta de pérdidas de memoria.
Si nada de eso funciona, deberías dirigirte aSitio web de Brendan Greggy empezarmedicióndiferentes indicadores de desempeño; También mira si puedes conseguir uno de sus libros. Por ejemplo, es posible que tenga algo así como una situación descontrolada con respecto a las asignaciones de memoria dentro de su raketarea. porque enfatizaslarga duraciónyintensivo en memoriapero estos no están necesariamente conectados. BPF y sus amigos le permitirán obtener información que de otro modo no obtendría.
Respuesta3
Por quéharía¿Será asesinado?
Porque no es automático que algo muera. Una vez que responda a eso y explique por qué se seleccionaría algo para su destrucción, es posible que pueda encontrar una solución.
Dado que estás hablando del rakecomando Rails, supongo que se trata de un proceso que se ejecuta en un servidor. El hecho de que le preocupe que lo eliminen sugiere que el servidor host lo está eliminando por usar demasiados recursos. En casos como este, no hay (ni debería haber) formas de detener el proceso de muerte.
Si tiene una tarea que requiere muchos recursos, compre más recursos. Utilice su propio tiempo de servidor. O llegue a un acuerdo con el anfitrión que le permita ejecutarlo por su cuenta.