Si escribo en mi shell x=`yes`, eventualmente lo obtendré cannot allocate 18446744071562067968 bytes (4295032832 bytes allocated)porque yesintenta escribir xpara siempre hasta que se queda sin memoria. Recibo un mensaje cannot allocate <memory>porque el OOM-killer del kernel me dijo xreallocque no hay más bytes para asignar y que debería salir inmediatamente.
Pero, cuando le pido a alguien game_engineque asigne más memoria gráfica que no existe porque no tengo recursos suficientes, recurre a mi RAM y CPU para asignar allí la memoria solicitada.
¿Por qué el OOM-killer del kernel nunca detecta ningún game_engineintento de asignar toneladas de memoria, como lo hace con x=`yes`?
Es decir, si estoy ejecutando game_enginey mi usuario no ha generado ningún proceso nuevo desde Memory-hog game_engine, ¿por qué dicho game_enginesiempre logra que mi sistema caiga de rodillas sin respuesta e irrecuperable sin que OOM-killer lo mate?
Utilizo los motores de juegos como ejemplo porque tienden a asignar toneladas y toneladas de memoria en mi pequeña y pobre tarjeta integrada, pero esto parece suceder con muchos procesos X que consumen muchos recursos.
¿Hay casos en los que el OOM-killer es ineficaz o no puede revocar la memoria de un proceso?
Respuesta1
Realmente, la mejor solución para el asesino de OOM es no tener uno. Configure su sistema para que no utilice memoria sobrecargada y rechace el uso de aplicaciones y bibliotecas que dependan de ella. En esta época de discos infinitos, ¿por qué no ofrecer un intercambio infinito? No es necesario comprometerse a realizar el intercambio a menos que se utilice la memoria, ¿verdad?
La respuesta a su pregunta puede ser que el asesino de OOM no funciona como usted cree. El asesino de OOM utiliza heurísticas para elegir qué proceso eliminar, y las reglas no siempre significan que el último solicitante muera. Cf.Domar al asesino OOM. Por lo tanto, no se trata de que el asesino de OOM sea "ineficaz", sino de que tome una decisión distinta a la que usted preferiría.