Obtenga un volcado de núcleo / depuración de un proceso eliminado por oom-killer

10

¿Hay alguna manera de obtener un volcado de núcleo o de depurar un proceso que ha sido asesinado por Oom-Killer?

¿O incluso configurar oom-killer para intentar matar un proceso usando ABRT en su lugar?

oom dump

— TrapAlice
fuente

5

Otro enfoque es deshabilitar el exceso de compromiso de memoria.

Para restaurar un poco de cordura en la administración de su memoria:

Deshabilitar el Asesino OOM (Poner vm.oom-kill = 0en /etc/sysctl.conf)

Desactivar overcommit memoria (Ponga vm.overcommit_memory = 2en /etc/sysctl.conf)

Esta configuración hará que Linux se comporte de la manera tradicional (si un proceso solicita más memoria de la que está disponible malloc()fallará y se espera que el proceso que solicita la memoria haga frente a esa falla).
Tenga en cuenta que este es un valor ternario:

0 = "estimar si tenemos suficiente RAM"

1 = "Siempre di que sí"

2 = "di no si no tenemos memoria"

Esto obligará a la aplicación a manejar el agotamiento de la memoria, y posiblemente sus registros / coredump / etc. podrían darle algo útil.

ACTUALIZACIÓN # 1

NOTA: ¡ Cuando su sistema se quede sin memoria, no podrá generar nuevos procesos! Puede ser bloqueado del sistema.

— nishantjr
fuente

Esta es una idea terrible. La mayoría del software que se ejecuta en su sistema probablemente no maneja el valor de retorno de la falla de asignación de memoria correctamente. Hacer esto provocará que se ejecuten rutas de código que prácticamente nadie ejecute y, en el peor de los casos, incluso podría introducir vulnerabilidades de seguridad en su sistema al ejecutar estas rutas de código inesperadas y no probadas.

— KJ Tsanaktsidis

4

echo 1 > /proc/sys/vm/oom_dump_tasks

que parece el máximo que puede hacer que el núcleo se muestre en errores de falta de memoria.

https://www.kernel.org/doc/Documentation/sysctl/vm.txt

Permite que se produzca un volcado de tareas en todo el sistema (excluyendo los hilos del kernel) cuando el kernel realiza una eliminación de OOM e incluye información como pid, uid, tgid, tamaño vm, rss, nr_ptes, swapents, oom_score_adj score y name. Esto es útil para determinar por qué se invocó al asesino OOM, para identificar la tarea deshonesta que lo causó y para determinar por qué el asesino OOM eligió la tarea que realizó para matar.

Si se establece en cero, esta información se suprime. En sistemas muy grandes con miles de tareas, puede que no sea posible volcar la información del estado de la memoria para cada una. Dichos sistemas no deberían verse obligados a incurrir en una penalización de rendimiento en condiciones OOM cuando la información no sea deseable.

Si se establece en un valor distinto de cero, esta información se muestra cuando el asesino de OOM realmente mata una tarea de acaparamiento de memoria.

— HBruijn
fuente