Depuración de memoria insuficiente con / var / log / messages

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, ¿cómo puedo continuar depurando el problema?

¿Cómo puedo obtener más información sobre por qué se mata 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`

El kernel habrá registrado un montón de cosas antes de que esto ocurriera, pero la mayoría probablemente no estará en /var/log/messagesfunción de cómo (r)syslogdesté configurado. Tratar:

grep oom /var/log/*
grep total_vm /var/log/*

El primero debería aparecer varias veces y el segundo en solo 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. Treinta segundos a un minuto (podría ser más, podría ser menos) antes de esa línea, encontrará algo como:

kernel: foobar invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0

También debe 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

Es posible que esto no le diga mucho más de lo que ya sabe, pero los campos son:

• pid El ID del proceso.
• ID de usuario uid .
• tgid ID de grupo de subprocesos.
• total_vm Uso de memoria virtual (en páginas de 4 kB)
• rss Uso de memoria residente (en páginas de 4 kB)
• nr_ptes Entradas de tabla de página
• swapents Intercambiar entradas
• oom_score_adj Generalmente 0; un número menor indica que el proceso tendrá menos probabilidades de morir cuando se invoca al asesino OOM.

En su mayoría, puede ignorar nr_ptesy, swapentsaunque creo que estos son factores para determinar quién es asesinado. Este no es necesariamente el proceso que usa más memoria, pero es muy probable que lo sea. Para obtener más información sobre el proceso de selección, consulte aquí . Básicamente, el proceso que termina con el puntaje OOM más alto se anula, ese es el "puntaje" informado en la línea "Sin memoria"; desafortunadamente, los otros puntajes no se informan, pero esa tabla proporciona algunas pistas en términos de factores.

Nuevamente, esto probablemente no hará mucho más que iluminar lo obvio: el sistema se quedó sin memoria y mysqldfue elegido para morir porque matarlo liberaría la mayoría de los recursos . Esto no significa necesariamente que mysqldesté haciendo algo mal. Puede mirar la tabla para ver si algo más se salió de la línea en ese momento, pero puede que no haya ningún culpable claro: el sistema puede quedarse sin memoria simplemente porque juzgó o configuró mal los procesos en ejecución.

La clave para esto está en el mensaje mismo: sin memoria . Cuando el kernel de Linux no tiene 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 e intercambio tiene el sistema? Consideraría agregar RAM adicional o, si eso no es posible, agregar intercambio adicional. Como una solución rápida para al menos evitar que se terminen los procesos, puede agregar un archivo de intercambio.

Actualización: Al observar la cantidad de RAM que tiene, puede ver el problema de inmediato. Tienes ~ 1.6GB de RAM y 100MB de intercambio, pero MySQL está usando mucha más RAM que eso. Eso explica por qué está viendo que los procesos se terminan.