Hoy en día no se le suele ver la cara, dado que la memoria de nuestro sistema suele ser grande, pero cuando por ejemplo, a un proceso se le va la mano y reserva más memoria de la que tiene nuestro sistema, entra en marcha un proceso especial del núcleo de Linux; el OOM Killer (Out Of Memory Killer), que se encarga de detectar qué proceso es el peor del sistema y matarlo.
Atendiendo a la documentación (oom_kill.c) tendremos tres opciones cuando nos quedamos sin memoria:
- Matar un proceso al azar (malo)
- Congelar el sistema (peor)
- Matar un proceso de forma inteligente
En fin, si el sistema no está configurado para congelarse (sysctl.kernel_panic_on_oom), intentaremos ver qué proceso tiene más papeletas para morir (el más dañino), y se hace asignando puntuaciones a procesos, en definitiva queremos matar un proceso malo en beneficio para el sistema, no queremos fastidiar diez horas de trabajo frente al ordenador (a menos que sea necesario).
Se sigue el siguiente algoritmo:
- Los primeros puntos a sumar son la cantidad de memoria del proceso
- Sumamos la memoria independiente de sus procesos hijos
- Los procesos con prioridad (nice) duplican la puntuación. Un proceso con nice si se come nuestra memoria compromete el sistema.
- Los procesos de superusuario dividen por 4 la puntuación. Los procesos de sistema o de superusuario no deberían dar ningún problema, y si root ejecutara algo… él/ella sabe lo que hace
![😉]()
- Miramos el valor de /proc/
/oom_adj (comprendido entre -17 y +15). Como usuarios, podemos aumentar o disminuir la probabilidad de que un proceso salga elegido para su sacrificio (por el bien del sistema). Si escribimos en ese fichero un -17, nuestro proceso no va a matarlo nunca el OOM killer
Como buen Linux, que nos deja como usuarios poder tocar su funcionamiento, tenemos lo siguiente:
- /proc/PID/oom_score : Puntuación de un proceso
- /proc/PID/oom_adj : Asignar o quitar papeletas para que un proceso sea sacrificado (como dije en la lista anterior). Es buena idea que si sabemos que un proceso puede colgar nuestro sistema, le demos un +15; si el sistema se lo carga, mejor; y si es algo importante aunque nuestro sistema ande falto de memoria, le damos un -17
- sysctl vm.panic_on_oom : En lugar de matar un proceso, lanza un kernel panic.
- Hay más reglas para configuración si buscamos dentro de sysctl y /proc/
¿Queremos saber qué proceso tiene, ahora mismo, más papeletas para ser sacrificado?
Si disponemos de /proc/sys/vm/oom_victim lo podremos ver ahí, si no, podemos ejecutar este script:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | min=0 for pid in `ps axo pid` do if [ -r /proc/$pid/oom_score ] then puntos=`cat /proc/$pid/oom_score`; if (( $puntos > $min )) then proceso=$pid; min=$puntos; fi fi done ps ax | grep $proceso |
Y lo más importante, queremos lanzarlo a mano, es decir, hay un proceso gastando mucha memoria y procesador, tanta, que no podemos hacer login en el sistema desde consola. Podemos hacer: Alt + SysRq + F y saltará un OMM Manual (Si sysctl kernel.sysrq = 1, o si no, el bit 7, o valor 64), es normal que se muera Firefox (gasta muchos recursos y Linux lo considera dañino para el sistema), Chrome o cualquier proceso que esté consumiendo muchos recursos 
Personalmente, tengo kernel.sysrq configurado en /etc/sysctl.conf con valor 240, para poder hacer RESIUB cuando el sistema se congela y también puedo hacer este OOM kill manual.
Foto: Joe Shlabotnik (Flickr)
The post Cuando un proceso “se come” la memoria de nuestro sistema appeared first on Poesía Binaria.