El siguiente informe aparece en mi registro de mensajes:
kernel: Out of memory: Kill process 9163 (mysqld) score 511 or sacrifice child
kernel: Killed process 9163, UID 27, (mysqld) total-vm:2457368kB, anon-rss:816780kB, file-rss:4kB
No importa si este problema es para httpd, mysqldo postfixtengo curiosidad por saber cómo puedo continuar depurando el problema.
¿Cómo puedo obtener más información sobre por qué se elimina el PID 9163 y no estoy seguro de si Linux mantiene el historial de los PID terminados en alguna parte?
Si esto ocurre en su archivo de registro de mensajes, ¿cómo solucionará este problema paso a paso?
# free -m
total used free shared buffers cached
Mem: 1655 934 721 0 10 52
-/+ buffers/cache: 871 784
Swap: 109 6 103`
Respuesta1
El kernel habrá registrado un montón de cosas antes de que esto sucediera, pero la mayoría probablemente no estará en /var/log/messages, dependiendo de cómo (r)syslogdesté configurado. Intentar:
grep oom /var/log/*
grep total_vm /var/log/*
El primero debería aparecer varias veces y el segundo sólo en uno o dos lugares. Ese es el archivo que desea ver.
Busque la línea original "Sin memoria" en uno de los archivos que también contiene total_vm. Entre treinta segundos y un minuto (podría ser más, podría ser menos) antes de esa línea encontrarás algo como:
kernel: foobar invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
También deberías encontrar una tabla en algún lugar entre esa línea y la línea "Sin memoria" con encabezados como este:
[ pid ] uid tgid total_vm rss nr_ptes swapents oom_score_adj name
Puede que esto no le diga mucho más de lo que ya sabe, pero los campos son:
- pidLa identificación del proceso.
- fluidoIdentificación de usuario.
- tgidID del grupo de subprocesos.
- total_vmUso de memoria virtual (en páginas de 4 kB)
- rssUso de memoria residente (en páginas de 4 kB)
- nr_ptesEntradas de la tabla de páginas
- intercambiosIntercambiar entradas
- oom_score_adjGeneralmente 0; un número más bajo indica que será menos probable que el proceso muera cuando se invoque el asesino OOM.
En su mayoría se puede ignorar nr_ptesy, swapentsaunque creo que estos son factores que determinan quién muere. Este no es necesariamente el proceso que utiliza más memoria, pero es muy probable que lo sea. Para más información sobre el proceso de selección,mira aquí. Básicamente, el proceso que termina con la puntuación más alta de Oom se elimina; esa es la "puntuación" informada en la línea "Sin memoria"; Lamentablemente, las otras puntuaciones no se informan, pero esa tabla proporciona algunas pistas en términos de factores.
Una vez más, esto probablemente no hará mucho más que iluminar lo obvio: el sistema se quedó sin memoria y mysqldse decidió morir.porque matarlo liberaría la mayor cantidad de recursos. Esto no significa necesariamente mysqldque esté haciendo algo mal. Puede mirar la tabla para ver si algo más salió fuera de lugar en ese momento, pero puede que no haya ningún culpable claro: el sistema puede quedarse sin memoria simplemente porque calculó mal o configuró mal los procesos en ejecución.
Respuesta2
La clave de esto está en el mensaje mismo:Sin memoria. Cuando el kernel de Linux se queda sin memoria virtual (RAM física más intercambio), comenzará a matar procesos y eso es exactamente lo que sucedió aquí. Parece que mysqldestaba usando más de 2 GB de memoria virtual.
¿Cuánta RAM y swap tiene el sistema? Consideraría agregar RAM adicional o, si eso no es posible, agregar intercambio adicional. Como solución rápida para al menos evitar que finalicen los procesos, puede agregar un archivo de intercambio.
Actualizar:Si observa la cantidad de RAM que tiene, podrá ver inmediatamente el problema. Tiene ~1,6 GB de RAM y 100 MB de intercambio, pero MySQL usa mucha más RAM que eso. Eso explica por qué ve que se finalizan procesos.