Solución 1:
La sobreasignación de memoria se puede desactivar con vm.overcommit_memory=2
0 es el modo predeterminado, donde el núcleo determina heurísticamente la asignación calculando la memoria libre en comparación con la solicitud de asignación que se realiza. Y establecerlo en 1 habilita el modo mágico, donde el núcleo siempre anuncia que tiene suficiente memoria libre para cualquier asignación. Si se establece en 2, significa que los procesos solo pueden asignar hasta una cantidad configurable (overcommit_ratio ) de RAM y comenzará a recibir mensajes de error de asignación o OOM cuando supere esa cantidad.
¿Es seguro hacerlo?, no. No he visto ningún caso de uso adecuado en el que deshabilitar la sobreasignación de memoria haya ayudado, a menos que esté 100 % seguro de la carga de trabajo y la capacidad del hardware. En caso de que esté interesado, instale kernel-docs paquete y vaya a /Documentation/sysctl/vm.txt para leer más, o leerlo en línea.
Si establece vm.overcommit_memory=2 luego se comprometerá en exceso hasta el porcentaje de RAM física configurado en vm.overcommit_ratio (el valor predeterminado es 50%).
echo 0/1/2 > /proc/sys/vm/overcommit_memory
Esto no sobrevivirá a un reinicio. Para persistencia, pon esto en /etc/sysctl.conf archivo:
vm.overcommit_memory=X
y ejecuta sysctl -p . No es necesario reiniciar.
Solución 2:
Declaración totalmente no calificada:deshabilitar la sobreasignación de memoria es definitivamente "más seguro" que habilitarla.
$el cliente lo tiene configurado en unos pocos cientos de servidores web y ayudó mucho con los problemas de estabilidad. Incluso hay un cheque de Nagios que grita muy fuerte si alguna vez NO se deshabilita.
Por otro lado, es posible que las personas no consideren "seguro" que sus procesos se agoten en la memoria cuando solo les gustaría comprometer un poco de ram y nunca lo usarían (es decir, SAP sería un muy buen ejemplo)
Entonces, vuelve a ver si mejora las cosas para ti. Dado que ya lo estás investigando para deshacerte de problemas relacionados, creo que podría ayudarte.
(Sé que me arriesgaré a un voto negativo de alguna persona gruñona)
Solución 3:
Acepto que deshabilitar el compromiso excesivo es más seguro que habilitarlo en algunas circunstancias. Si el servidor ejecuta solo algunos trabajos de memoria grandes (como simulaciones de circuitos en mi caso), es mucho más seguro negarle a la aplicación la solicitud de memoria por adelantado en lugar de esperar un evento OOM (que seguramente seguirá en breve) Muy a menudo vemos servidores tener problemas después de que el asesino OOM haya hecho su trabajo.