Evite el desmontaje de la aplicación Linux sin memoria

34

Estoy descubriendo que en ocasiones mi caja de Linux se queda sin memoria y comienza a destruir procesos aleatorios para lidiar con ella.

Tengo curiosidad por saber qué hacen los administradores para evitar esto. ¿Es la única solución real para aumentar la cantidad de memoria (solo ayudará el intercambio?) ¿O hay mejores formas de configurar la caja con software para evitar esto? (es decir, cuotas o algo así?).

Eddie Parker
fuente
Encontré una respuesta aquí: serverfault.com/questions/362589/… La respuesta de Patrick es muy instructiva
Amaury

Respuestas:

44

Por defecto, Linux tiene un concepto de administración de memoria algo dañado por el cerebro: le permite asignar más memoria de la que tiene su sistema, luego dispara aleatoriamente un proceso en la cabeza cuando se mete en problemas. (La semántica real de lo que se mata es más compleja que eso: Google "Linux OOM Killer" para obtener muchos detalles y argumentos sobre si es algo bueno o malo).


Para restaurar un poco de cordura en la administración de su memoria:

  1. Deshabilitar el Asesino OOM (Poner vm.oom-kill = 0en /etc/sysctl.conf)
  2. Deshabilite el exceso de memoria (Ponga vm.overcommit_memory = 2en /etc/sysctl.conf)
    Tenga en cuenta que este es un valor trinario: 0 = "estimar si tenemos suficiente RAM", 1 = "Siempre diga sí", 2 = "diga no si no tener la memoria ")

Esta configuración hará que Linux se comporte de la manera tradicional (si un proceso solicita más memoria de la que está disponible, malloc () fallará y se espera que el proceso que solicita la memoria haga frente a esa falla).

Reinicie su máquina para que se vuelva a cargar /etc/sysctl.conf, o use el procsistema de archivos para habilitarla de inmediato, sin reiniciar:

echo 2 > /proc/sys/vm/overcommit_memory 
voretaq7
fuente
11
No es Linux lo que sufrió daños cerebrales, sino los programadores que asignan la memoria, para nunca usarla. Las máquinas virtuales Java son notorias con esto. Yo, como administrador que gestiona servidores que ejecutan aplicaciones Java, no sobreviviría un segundo sin un compromiso excesivo.
Aleksandar Ivanisevic
11
Los programadores de Java no asignan memoria no utilizada, no hay malloc en java. Creo que estás confundiendo esto con la configuración de JVM como -Xms. En cualquier caso, aumentar el tamaño de la memoria virtual al agregar espacio de intercambio es una solución mucho más segura que el exceso de compromiso.
jlliagre
55
Tenga en cuenta que esta solución no impedirá que su sistema se quede sin memoria o elimine procesos. Solo lo revertirá al comportamiento tradicional de Unix, donde si un proceso consume toda su memoria, el siguiente que intente malloc no obtendrá ninguno (y lo más probable es que se bloquee). Si no tienes suerte, el siguiente proceso es init (o algo más que sea crítico), que el OOM Killer generalmente evita.
pehrs
8
jlliagre, dije máquinas virtuales Java (máquinas virtuales), no programas Java, aunque desde la perspectiva del administrador es lo mismo :)
Aleksandar Ivanisevic
8
Quizás valga la pena mencionar aquí que agregar lo anterior /etc/sysctl.confprobablemente solo tenga efecto en el próximo reinicio; si desea realizar cambios ahora , debe usar el sysctlcomando con permisos de root, por ejemplosudo sysctl vm.overcommit_memory=2
nickgrim
3

La respuesta corta, para un servidor, es comprar e instalar más RAM.

Un servidor que habitualmente experimentó errores OOM (sin memoria), luego, además de la opción sysctl de sobrecompromiso del administrador de VM (memoria virtual) en los núcleos de Linux, esto no es algo bueno.

Aumentar la cantidad de intercambio (memoria virtual que el administrador de memoria del núcleo ha paginado en el disco) ayudará si los valores actuales son bajos, y el uso implica muchas tareas, tales como grandes cantidades de memoria, en lugar de una o algunas procesa cada una solicitando una gran cantidad de memoria virtual total disponible (RAM + intercambio).

Para muchas aplicaciones que asignan más de dos veces (2 veces) la cantidad de RAM como intercambio proporciona un rendimiento decreciente en la mejora. En algunas simulaciones computacionales grandes, esto puede ser aceptable si la ralentización de la velocidad es soportable.

Con RAM (ECC o no) ser bastante asequible para cantidades modestas, por ejemplo, 4-16 GB, tengo que admitir que no he experimentado este problema en mucho tiempo.

Los conceptos básicos para ver el consumo de memoria incluyen el uso freey top, ordenados por uso de memoria, como las dos evaluaciones rápidas más comunes de los patrones de uso de memoria. Por lo tanto, asegúrese de comprender el significado de cada campo en la salida de esos comandos como mínimo.

Sin datos específicos de las aplicaciones (por ejemplo, base de datos, servidor de servicio de red, procesamiento de video en tiempo real) y el uso del servidor (pocos usuarios avanzados, 100-1000s de conexiones de usuario / cliente), no puedo pensar en ninguna recomendación general con respecto a tratar El problema OOM.

mctylr
fuente
3

El aumento de la cantidad de memoria física puede no ser una respuesta efectiva en todas las circunstancias.

Una forma de verificar esto es el comando 'encima'. Particularmente estas dos líneas.

Esto es fuera del servidor cuando estaba en buen estado:

MEM | tot   23.7G | free   10.0G | cache   3.9G | buff  185.4M | slab  207.8M |
SWP | tot    5.7G | free    5.7G |              | vmcom  28.1G | vmlim  27.0G |

Cuando funcionaba mal (y antes de ajustar overcommit_memory de 50 a 90, veíamos un comportamiento con vmcom que se ejecutaba por encima de 50G, procesos de explosión de Oom-killer cada pocos segundos, y la carga seguía rebotando radicalmente debido a que los procesos secundarios NFSd se volcaban arriba y recreado continuamente.

Recientemente hemos duplicado casos en los que los servidores de terminal de Linux multiusuario comprometen de forma masiva la asignación de memoria virtual, pero muy pocas de las páginas solicitadas se consumen realmente.

Si bien no se recomienda seguir esta ruta exacta, ajustamos el exceso de memoria de los valores predeterminados de 50 a 90, lo que alivió parte del problema. Terminamos teniendo que mover a todos los usuarios a otro servidor de terminal y reiniciar para ver el beneficio completo.

Magallanes
fuente
2

Puede usar ulimit para reducir la cantidad de memoria que un proceso puede reclamar antes de que se elimine. Es muy útil si su problema es uno o algunos procesos que se ejecutan y que bloquean su servidor.

Si su problema es que simplemente no tiene suficiente memoria para ejecutar los servicios que necesita, solo hay tres soluciones:

  1. Reduzca la memoria utilizada por sus servicios limitando los cachés y similares

  2. Crea un área de intercambio más grande. Te costará en rendimiento, pero puede comprarte algo de tiempo.

  3. Compra más memoria

pehrs
fuente
0

Tuve un problema similar relacionado con este error y la solución fue usar un kernel más antiguo / nuevo (fijo).

Sin embargo, en ese momento no pude reiniciar mi máquina, por lo que una especie de solución fea fue iniciar sesión como root y borrar cachés del sistema con este comando:

echo 3 > /proc/sys/vm/drop_caches
Krzysztof Dryja
fuente
-5

@ voretaq7 Linux no tiene un concepto de administración de memoria con daño cerebral, por defecto vm.overcommit_ratio es 0,

0       -   Heuristic overcommit handling. Obvious overcommits of
            address space are refused. Used for a typical system. It
            ensures a seriously wild allocation fails while allowing
            overcommit to reduce swap usage.  root is allowed to
            allocate slightly more memory in this mode. This is the
            default.

De esta manera, si tiene 4 GB de RAM e intenta asignar 4,2 GB con malloc de memoria virtual, su asignación fallará.

Con vm.overcommit_ratio = 1

            1    -   Always overcommit. Appropriate for some scientific
            applications. Classic example is code using sparse arrays
            and just relying on the virtual memory consisting almost
            entirely of zero pages.

Con vm.overcommit_ratio = 2

           2    -   Don't overcommit. The total address space commit
            for the system is not permitted to exceed swap + a
            configurable percentage (default is 50) of physical RAM.
            Depending on the percentage you use, in most situations
            this means a process will not be killed while accessing
            pages but will receive errors on memory allocation as
            appropriate.

            Useful for applications that want to guarantee their
            memory allocations will be available in the future
            without having to initialize every page.

Entonces, por defecto, Linux no se compromete demasiado, si su aplicación tiene más memoria que la que tiene, tal vez su código tenga errores

c4f4t0r
fuente
2
Te has contradicho aquí. En la parte superior, dice "por defecto vm.overcommit_ratio es 0" y luego en la parte inferior dice "por defecto, Linux no se compromete en exceso". Si esto último fuera cierto, vm.overcommit_ratio sería 2 por defecto.
Michael Hampton
vm.overcommit_ratio = 0, malloc no asigna más memoria que su ram físico, por lo que para mí eso significa no comprometerse demasiado, overcommit es cuando puede asignar más virtual que su ram físico
c4f4t0r
2
Sí, has entendido mal.
Michael Hampton
entendiste mal, el valor predeterminado 0, no se asigna para asignar más memoria virtual que ram y 2 no se excede, permite vm.overcommit_ratio + espacio de intercambio, así que si no lo
entendí,
2
Por supuesto. Se rechazan las "sobrecomisiones obvias". El resto pasa. Necesitas leer más cuidadosamente.
Michael Hampton