¿Por qué el OOM-Killer no puede simplemente matar el proceso que pide demasiado?

Aquí se explica que el OOM-Killer se puede configurar a través de overcommit_memoryy que:

2 = sin exceso de compromiso. Las asignaciones fallan si se pide demasiado.
0, 1 = sobrecompromiso (heurísticamente o siempre). Elimine algunos procesos basados en algunas heurísticas cuando realmente se accede a demasiada memoria.

Ahora, puedo entender completamente mal eso, pero ¿por qué no hay una opción (o por qué no es la predeterminada) para eliminar el proceso que realmente intenta acceder a demasiada memoria que asignó?

linux out-of-memory

— Martin Ba
fuente

¿Qué sucede si un proceso crítico del sistema requiere demasiada memoria?

— Lawrence

En primer lugar, puede hacer esto. Pero, el mayor problema con esa pregunta es que, con toda probabilidad, si un proceso está pidiendo memoria, entonces se está ejecutando nuevamente , o, en otras palabras, este es un nuevo proceso involucrado en el procesamiento muy actual. ¿Preferiría que el OOM permitiera que su cliente im no abierto durante 3 días siga desperdiciando memoria del sistema o preferiría que YouTube realmente se cargara en algún momento este año? linuxatemyram.com

— mikeserv

Esto es lo que no overcommitesencialmente hace la opción. Si un proceso solicita demasiada memoria, falla. Si verifica el error, generalmente se suicidará; si no lo hace, probablemente obtendrá un Error de segmentación cuando intente desreferenciar el puntero nulo que malloc()regresa, y se bloqueará.

— Barmar

Tenga en cuenta que 2 es en realidad el no overcommitmodo, de acuerdo con las fuentes citadas (como kernel.org/doc/Documentation/vm/overcommit-accounting ). Creo que editaré tu pregunta en consecuencia.

— hans_meine

Considere este escenario:

Tienes 4 GB de memoria libre.
Un proceso defectuoso asigna 3.999GB.
Abre un administrador de tareas para matar el proceso desbocado. El administrador de tareas asigna 0.002GB.

Si el proceso que fue asesinado fue el último en solicitar memoria, su administrador de tareas sería asesinado.

Tienes 4 GB de memoria libre.
Un proceso defectuoso asigna 3.999GB.
Abre un administrador de tareas para matar el proceso desbocado. El servidor X asigna 0.002GB para manejar la ventana del administrador de tareas.

Ahora su servidor X es asesinado. No causó el problema; simplemente estaba "en el lugar equivocado en el momento equivocado". Resultó ser el primer proceso en asignar más memoria cuando no quedaba nada, pero no fue el proceso que utilizó toda la memoria para comenzar.

— usuario253751
fuente

Extender su ejemplo significa que si un proceso consumiera el 99.999% de su memoria, nunca sería capaz de matarlo, ya que cualquier cosa que pudiera matarlo requeriría memoria y, por lo tanto, moriría antes de que el proceso errante pudiera morir.

— Trineo

Eso sí, esta es la filosofía de Linux, no un hecho necesario. Windows 3.0 lo resolvió al tener suficiente memoria reservada para el manejo de OOM, incluidos los cuadros de diálogo necesarios.

— MSalters

@MSalters: Sin embargo, eso realmente no se aplica al ejemplo; El ejemplo fue sobre un proceso que ha reservado casi toda la memoria, es decir. no es suficiente para que OOM sea asesinado. Obviamente, debe haber suficiente memoria reservada para el manejo de OOM en cualquier sistema operativo. Pero el proceso que invoca el manejo de OOM sería el siguiente proceso que reserva memoria, no el mal comportamiento. A menos, por supuesto, que quisieras decir que Windows 3.0 siempre tenía suficiente memoria reservada para ejecutar el administrador de tareas, o que el controlador OOM siempre le pedía al usuario que eliminara el proceso. (¡Qué! =

— Matar

@ Aleksi Torhamo: De hecho, me refería a esto último. Windows 3.0 no tenía un administrador de tareas completo, tenía las famosas pantallas azules cuya memoria estaba preasignada.

— MSalters