Publi

Cuando un proceso «se come» la memoria de nuestro sistema

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)

También podría interesarte....

There are 17 comments left Ir a comentario

  1. Pingback: Bitacoras.com /

  2. Pingback: Cuando un proceso se come la memoria del sistema /

  3. rafa /
    Usando Google Chrome Google Chrome 5.0.384.0 en Linux Linux

    Muchas gracias…
    Me gustaría ya de paso, que el script , en bash lo copie, no funciona,sale

    procesos.sh: 15: 203: not found
    Y el grep al final falla.
    De todas maneras, ¿ donde sacastes esta información ?

  4. admin / Post Author
    Usando Mozilla Firefox Mozilla Firefox 3.6 en Linux Linux

    @rafa
    Da la impresión de que el PID es 203, y parece que no hace el grep simplemente ejecuta el PID. Puedes intentar hacer un

    echo $proceso

    antes del ps y luego el

    ps ax | grep [lo que te salio antes]

    a mano. Me gustaría saber qué te dice, y así corregimos el script, yo lo he probado en varios equipos y me funciona bien.

    La info. la he sacado de los dos links que hay en el post, el script lo hice yo.

  5. Fede /
    Usando Google Chrome Google Chrome 5.0.342.9 en Linux Linux

    No creo que Firefox se devore más que Chromium, ¡1 GB!
    Si dejo por más de 5 horas a Chromium abierto ocupa eso o más.

  6. admin / Post Author
    Usando Mozilla Firefox Mozilla Firefox 3.6 en Linux Linux

    @Fede
    Wow !! Qué bestialidad !! Con eso de 1 pestaña, 1 proceso es lo que tiene, las partes comunes se replican.

    Yo aún sigo adicto a Firefox y más aún a las extensiones que tengo instaladas…

  7. Pingback: Poesía binaria » REISUB y llamadas remotas a Alt+Sysrq /

  8. Pingback: Poesía binaria » Limitando recursos en ImageMagick /

  9. Pingback: Poesía binaria » Iniciación a los memory leaks [ejemplos en C++] /

  10. Kr0m /
    Usando Mozilla Firefox Mozilla Firefox 31.0 en Linux Linux

    Te he retocado un poco el script, creo que así está mas completo:
    #! /bin/bash

    min=0
    for pid in $(ps axo pid); do
    if [ -r /proc/$pid/oom_score ]; then
    puntos=$(cat /proc/$pid/oom_score)
    #echo -e «PID: $pid — Puntos: $puntos — Min: $min»
    if [ $puntos -gt $min ]; then
    proceso=$pid
    min=$puntos
    fi
    fi
    done

    if [ $min -eq 0 ]; then
    echo -e » »
    echo -e «—————————————————»
    echo -e «– Todos los procesos del sistema con 0 papeletas»
    echo -e «—————————————————»
    else
    ps ax | grep $proceso
    fi

    1. Gaspar Fernández / Post Author
      Usando Mozilla Firefox Mozilla Firefox 35.0 en Ubuntu Linux Ubuntu Linux

      Muchas gracias Kr0m !

      Por cierto, muy interesante tu blog! 🙂

  11. Pingback: Cuando un proceso “se come” la memoria de nuestro sistema – Poesía Binaria – PROYECTO TIC – TAC /

  12. Oscar /
    Usando Mozilla Firefox Mozilla Firefox 52.0 en Fedora Linux Fedora Linux

    Hola!

    Una pregunta muy tonta: entiendo que si «hay problemas», el proceso con mayor puntuación muere pero …¿dónde se define el umbral de esos «problemas»? ¿Es un determinado % de cpu? ¿Es un determinado % de mem?

    Y por otro lado, si se detecta que hay un proceso que se «está pasando», ¿ no debería ser supérfluo el OMM Manual? ¿Es decir, no debería ser Linux lo suficientemente listo para lanzar el killer automáticamente siempre?

    Gracias!

    Y Muchas felicitaciones por estos artículos tan interesantes

    1. Gaspar Fernández / Post Author
      Usando Mozilla Firefox Mozilla Firefox 52.0 en Ubuntu Linux Ubuntu Linux

      Hola Oscar,
      No hay forma de configurar un umbral para el OOM killer. Se considera que esto es un último recurso y se lanza cuando el sistema no tenga memoria. Es decir, cuando un programa pida una serie de bytes y no haya de dónde sacarlos. Entonces, se mira la tabla de procesos y las puntuaciones de cada uno y el que más papeletas tenga será el asesinado (muahaha). En el kernel 4.6 hay cambios en este sistema aunque son para realizar la liberación de memoria de forma más inteligente.

      En relación a tu segunda pregunta, actualmente contamos con sistemas que vigilan los procesos que se están pasando. Por ejemplo con ulimit o con la configuración de /etc/security/limits.conf ; de todas formas, si tienes los límites desactivados, que es común en escritorio, porque siempre puedes ejecutar puntualmente un programa que se pase para comprimir vídeo por ejemplo, o generar una imagen tienes como plan B el killer manual. Es decir, algunas veces el proceso se pasará y nos gustaría esperar a que finalizara, otras veces, vemos que el proceso se ha ido de madre y lo matamos a mano (eso si el sistema no se queda sin memoria que es cuando se lanza el OOM killer automáticamente).

      Gracias por leerme! Y perdona la tardanza en contestar, he estado un tiempo fuera.

      1. Oscar /
        Usando Mozilla Firefox Mozilla Firefox 52.0 en Fedora Linux Fedora Linux

        Muchísimas gracias por la respuesta, por el blog y por todo!!!

        1. Gaspar Fernández / Post Author
          Usando Mozilla Firefox Mozilla Firefox 52.0 en Ubuntu Linux Ubuntu Linux

          ¡¡Gracias a ti!! Encantado de que te pases por aquí 🙂

  13. Officer Amini Tracker Black Jacket /
    Usando Google Chrome Google Chrome 121.0.0.0 en Windows Windows NT

    This is a great inspiring article. I am pretty much pleased with your good work. You put really very helpful information.

Leave a Reply to rafa Cancle Reply