Evite el desmontaje de aplicaciones sin memoria de Linux

Solución 1:

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

Para restaurar una apariencia de cordura en la gestión de su memoria:

1. Desactivar OOM Killer (Poner vm.oom-kill = 0 en /etc/sysctl.conf)
2. Deshabilitar la sobreasignación de memoria (Poner vm.overcommit_memory = 2 en /etc/sysctl.conf)
   Tenga en cuenta que este es un valor trinario:0 ="estimar si tenemos suficiente RAM", 1 ="Siempre decir que sí", 2 ="decir no si no tenemos 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 usa el proc sistema de archivos para habilitar de inmediato, sin reiniciar:

echo 2 > /proc/sys/vm/overcommit_memory 

Solución 2:

Puede deshabilitar la sobreasignación, consulte http://www.mjmwired.net/kernel/Documentation/sysctl/vm.txt#514

Solución 3:

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

Un servidor que rutinariamente experimentaba OOM (Out-Of-Memory), además de la opción overcommit sysctl del administrador de VM (memoria virtual) en los kernels de Linux, esto no es algo bueno.

Aumentar la cantidad de intercambio (memoria virtual que el administrador de memoria del kernel ha paginado en el disco) ayudará si los valores actuales son bajos y el uso implica muchas tareas, cada una con grandes cantidades de memoria, en lugar de una o unas pocas. procesa cada uno solicitando una gran cantidad de la memoria virtual total disponible (RAM + swap).

Para muchas aplicaciones, la asignación de más del doble (2x) de la cantidad de RAM como intercambio proporciona un rendimiento de mejora decreciente. En algunas simulaciones computacionales grandes, esto puede ser aceptable si la desaceleración de la velocidad es soportable.

Con RAM (ECC o no) sea bastante asequible para cantidades modestas, p. 4-16 GB, debo admitir que no he experimentado este problema en mucho tiempo.

Los conceptos básicos para observar el consumo de memoria, incluido el uso de free y top , ordenados por uso de memoria, como las dos evaluaciones rápidas más comunes de patrones de uso de memoria. Así que asegúrese de comprender el significado de cada campo en la salida de esos comandos como mínimo.

Sin detalles específicos de las aplicaciones (por ejemplo, base de datos, servidor de servicios 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 con el problema OOM.

Solución 4:

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 varios procesos que fallan y 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 cachés y similares

2. Cree un área de intercambio más grande. Le costará en rendimiento, pero puede comprarle algo de tiempo.

3. Comprar más memoria

Solución 5:

Es posible que aumentar la cantidad de memoria física no sea una respuesta eficaz en todas las circunstancias.

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

Este es nuestro 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 que ajustáramos overcommit_memory de 50 a 90), veíamos un comportamiento con vmcom funcionando muy por encima de 50 G, oom-killer explotando procesos cada pocos segundos, y la carga seguía rebotando radicalmente debido a que los procesos secundarios de NFSd explotaban arriba y recreado continuamente.

Recientemente hemos duplicado casos en los que los servidores de terminales Linux multiusuario sobreasignan masivamente 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 la memoria de compromiso excesivo del valor predeterminado 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.