Respuesta personalizada LInux OOM

Estoy ejecutando el server web de Apache y me gustaría mejorar un poco cómo se maneja la situación del OOM.

Estoy atento a las puntuaciones de OOM y ya hizo algunas personalizaciones en ese asunto, así que cuando algo malo sucede, Linux está matando los processs correctos. Pero no es suficiente.

El problema es que a veces, cuando ocurre OOM, el server se sobrecarga y luego se bloquea y debe reiniciarse. Me gustaría manejar eso sin el reinicio completo del server. Así que necesito de alguna manera "enganchar" una escritura en la invocación del asesino de OOM que mataría todos los processs de apache (y sus CGIs), liberando así la memory y la comienzo (Apache) otra vez.

Sé que esto funcionaría, porque si ocurre OOM y soy lo suficientemente rápido para iniciar session en el server y matar el manual de Apache, todo está bien entonces.

FYI Estoy corriendo ahora casi un centenar de los serveres web, thats por qué estoy buscando la solución totalmente automática.

Una posible solución sería, por supuesto, usar algún perro guardián que analizara el syslog y detectara MOOs de esta manera. Ya tengo algo así, que notifica sobre matanzas de OOM por e-mail. Esta aproximación puede resolver algunas situaciones pero si el OOM es realmente malo, el server está demasiado sobrecargado y mi script ni siquiera se inicia (su ejecución por cron). Se puede mejorar utilizando inotify para ver el syslog o cparsing el syslog directamente (es decir, por fifo) a la secuencia de commands.

Pero todavía me estoy preguntando – no hay ninguna manera de cómo "gancho" el guión directamente a OOM asesino? Así que me gustaría poner algo así en algunos / etc / .. file:

oom_action="sh /path/to/my/script.sh kill" 

¿O simplemente no es posible hacerlo así?

Estoy utilizando Centos 6, Apache 2.2 y PHP como FastCGI.

¿Por qué no acaba de supervisar los processs de apache y establecer su valor oom_adj a 15 para estar seguro de que será el primero en terminar en OOM? Aquí hay algunas instrucciones sobre esta configuration.

Dependiendo de su configuration, puede modificar scripts de inicio de apache o configurar una tarea cron simple para hacerlo.

También puede ver periódicamente la salida del command dmesg | grep -i oom dmesg | grep -i oom . Si habrá alguna línea, matador de OOM mató a alguien desde que el server fue arrancado la última vez. A continuación, puede borrar el búfer con dmesg --clear

Sé que hay horribles aplicaciones de PHP en la naturaleza, muchos de ellos, pero no hay algo que podría hacer en el lado de Apache / FastCGI / PHP de las cosas? Apache constantemente OOMing no es algo que usted debe encontrar con mucha frecuencia.

Trate de networkingucir el número máximo de processs Apache y controlleres FastCGI, y ver si la configuration actual de php.ini es demasiado alta para la memory máxima por secuencia de commands.

Además, es perfectamente posible usar ulimit con Apache y restringir el número de memory que un process puede usar. Eso puede ayudarle antes de que el server casi espirales a la muerte.

OOM es el último recurso, y todo lo que puede conducir a él debe ser inspeccionado.

Como no encontré ninguna solución mejor, he implementado el watchdog para leer los posts syslog del kernel (a través de fifo):

/etc/rsyslog.d:

 (...) kern.err |/path/to/fifo 

y searchlos para la actividad OOM-killer:

while read /path/to/fifo; do (..)

y cuando el OOM-killer desova masivamente (i realmente necesidad de comprobar sólo para la situación de emergencia), matar (y luego iniciar) Apache.

Creo que es mejor que ponga su process en el subgrupo de memory cgroup y use el release_agent para llamar a un script externo cuando ocurre la memory

 notify_on_release contains a Boolean value, 1 or 0, that either enables or disables the execution of the release agent. If the notify_on_release is enabled, the kernel executes the contents of the release_agent file when a cgroup no longer contains any tasks (that is, the cgroup's tasks file contained some PIDs and those PIDs were removed, leaving the file empty). A path to the empty cgroup is provided as an argument to the release agent. release_agent (present in the root cgroup only) contains a command to be executed when a “notify on release” is triggenetworking. Once a cgroup is emptied of all processes, and the notify_on_release flag is enabled, the kernel runs the command in the release_agent file and supplies it with a relative path (relative to the root cgroup) to the emptied cgroup as an argument. The release agent can be used, for example, to automatically remove empty cgroups 

Con cgroup puede controlar la cantidad de resources que puede procesar y no poner su server de sobrecarga

 Using cgroup you can control the server resources