Cuando Linux se queda sin memoria (OOM), el asesino OOM elige un proceso para matar basado en algunos heurísticos (es una lectura interesante: http://lwn.net/Articles/317814/).Encontrar qué proceso fue asesinado por OOM asesino de Linux
¿Cómo puede uno programáticamente determinar qué procesos han sido asesinados recientemente por el OOM killer?
Trate de hacer esto:
grep -i 'killed process' /var/log/messages
probar esto:
grep "Killed process" /var/log/syslog
probar esto por lo que no es necesario que preocuparse de donde sus registros son
dmesg | egrep -i 'killed process'
Esto también es útil, pero aunque desafortunadamente no puedo explicarlo, estoy viendo resultados en '/ var/log/messages' que no aparecen en' dmesg'/'/ var/log/dmesg'. Podría ser algún tipo de error de configuración, pero vale la pena señalar que el uso de ambos enfoques podría ser una buena idea. – kungphu
No estoy seguro acerca de su archivo de registro, pero la salida de dmesg es de un buffer de anillo de tamaño limitado. Si otras cosas han llenado el búfer desde el asesino mortal, perderás la producción del asesino mortal. –
Esta fue la única forma en que encontré cómo ver que el proceso se eliminó en el contenedor OpenVZ – igo
que sé este es un hilo histórico, pero ahora dstat proporciona la función para averiguar en su sistema operativo qué proceso es candidato para ser asesinado por un mecánico ismo
dstat --top-oom
--out-of-memory---
kill score
java 77
java 77
java 77
y según la página hombre
--top-oom
show process that will be killed by OOM the first
Fwiw, consigo esos mensajes en syslog, o kern.log, pero no/var/log/messages – jberryman
Puede usar "egrep -i - r 'proceso muerto'/var/log/"para buscarlo también en otros lugares. – metdos
@jberryman: Por alguna razón, syslog está en '/ var/log/syslog' en algunas distribuciones, y'/var/log/messages' en otras. Creo que es Debian para el primero y Red Hat para el segundo, BICBW. –