La razón por la que el OOM-killer no se llama automáticamente es porque el sistema, aunque se ralentizó por completo y ya no responde cuando se acerca a la falta de memoria y, en realidad no ha llegado a la situación de falta de memoria.
Demasiado simplificado, la RAM casi llena contiene 3 tipos de datos:
- datos del kernel, eso es esencial
- páginas de datos esenciales del proceso (p. ej., cualquier dato que el proceso haya creado solo en RAM)
- páginas de datos de proceso no esenciales (por ejemplo, datos como el código de los ejecutables, para los cuales hay una copia en el disco/en el sistema de archivos, y que, mientras están actualmente asignados a la memoria, podrían "volver a leerse" desde el disco al usarlos )
En una situación de falta de memoria, el kernel de Linux, por lo que puedo decir, es kswapd0 El subproceso del kernel, para evitar la pérdida de datos y la pérdida de funcionalidad, no puede descartar 1. y 2. , pero tiene la libertad de eliminar al menos temporalmente los datos asignados a los archivos de memoria de la RAM que forman procesos que no se están ejecutando actualmente.
Si bien este es un comportamiento que involucra la destrucción del disco, desechar datos constantemente y volver a leerlos desde el disco puede verse como útil, ya que evita, o al menos pospone, la eliminación/eliminación necesaria de un proceso y la liberación-pero-también- perdiendo la memoria, tiene un subidón precio:rendimiento.
[load pages from disk to ram with code of executable of process 1]
[ run process 1 ]
[evict pages with binary of process 1 from ram]
[load pages from disk to ram with code of executable of process 2]
[ run process 2 ]
[evict pages with binary of process 2 from ram]
[load pages from disk to ram with code of executable of process 3]
[ run process 3 ]
[evict pages with binary of process 3 from ram]
....
[load pages from disk to ram with code of executable of process 1]
[ run process 1 ]
[evict pages with binary of process 1 from ram]
es claramente IO costoso y es probable que el sistema deje de responder, aunque técnicamente todavía no se ha agotado por completo de la memoria.
Sin embargo, desde la perspectiva del usuario, parece ser que estar colgado/congelado y la interfaz de usuario que no responde resultante podría no ser realmente preferible, en lugar de simplemente eliminar el proceso (por ejemplo, de una pestaña del navegador, cuyo uso de memoria podría haber sido la causa principal/culpable de comenzar con.)
Aquí es donde, como indica la pregunta, el disparador de la tecla Magic SysRq para iniciar el OOM manualmente parece excelente, ya que Magic SysRq se ve menos afectado por la falta de respuesta del sistema.
Si bien puede haber casos de uso en los que es importante preservar los procesos (rendimiento ), para una computadora de escritorio, es probable que los usuarios prefieran el OOM-killer sobre la interfaz de usuario congelada. Hay un parche que pretende eximir de la memoria los archivos respaldados por fs mapeados limpios en tal situación en esta respuesta en stackoverflow.
Puede ver el archivo /sys/fs/cgroup/memory/memory.oom_control durante una prueba de esfuerzo.
o
Puede consultar la fecha de la última modificación para ver si se modificó en el momento del último bloqueo. Esto le dirá si incluso estaba intentando hacer su trabajo.
under_oom 0
Ese es tu problema:
under_oom 0 or 1 (if 1, the memory cgroup is under OOM, tasks may
be stopped.)
Si se establece en 1, significa que está bajo control oom. Activado.
Si se establece en 0, así no está bajo control oom. Deshabilitado.