De vez en cuando "mi" servidor se detiene porque se queda sin memoria y espacio de intercambio. (sigue respondiendo al ping pero nada más que eso, ni siquiera ssh).
Me han dicho que Linux tiene un compromiso excesivo de memoria, que hasta donde yo entiendo es lo mismo que hacen los bancos con el dinero: otorga a los procesos más memoria de la que está realmente disponible, suponiendo que la mayoría de los procesos no usen toda la memoria que piden, en al menos no todos al mismo tiempo.
Suponga que esta es realmente la causa por la que mi sistema se bloquea ocasionalmente, no discutamos aquí si este es el caso (consulte ¿Qué puede causar que TODOS los servicios en un servidor se caigan, y aún así responda al ping? Y cómo averiguarlo ) .
Asi que,
¿Cómo deshabilito o reduzco drásticamente el exceso de memoria en CentOS? He leído que hay dos configuraciones llamadas vm.overcommit_memory (valores 0, 1 o 2) y vm.overcommit_ratiom pero no tengo idea de dónde tengo que encontrarlas y cambiarlas (algunos archivos de configuración con suerte), ¿qué valores debo probar? y si necesito reiniciar el servidor para que los cambios sean efectivos.
y es seguro ¿Qué efectos secundarios puedo esperar? Cuando busco en Google overcommit_memory, encuentro cosas aterradoras como que la gente dice que su servidor ya no puede arrancar ...
Dado que lo que causa el aumento repentino en el uso de la memoria es mysql debido a las consultas realizadas por php, que a su vez se llama mientras se atienden las solicitudes http, esperaría que solo algunos script php no se completen y, por lo tanto, algunas respuestas de 500 de vez en cuando el servidor está demasiado ocupado, lo cual es un riesgo que puedo tomar (ciertamente mejor que el servidor completo se vuelva inaccesible y tenga que reiniciarlo).
¿O realmente puede hacer que mi servidor no pueda reiniciarse si elijo la configuración incorrecta?
Respuestas:
El exceso de memoria se puede deshabilitar
vm.overcommit_memory=20 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 de asistente, donde el núcleo siempre anuncia que tiene suficiente memoria libre para cualquier asignación. La configuración a 2 significa que los procesos solo pueden asignar hasta una cantidad configurable (
overcommit_ratio) de RAM y comenzarán a recibir errores de asignación o mensajes OOM cuando superen esa cantidad.¿Es seguro hacerlo, no? No he visto ningún caso de uso adecuado en el que la desactivación de la sobrecompromiso de memoria realmente 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 el
kernel-docspaquete y vaya/Documentation/sysctl/vm.txta leer más, o léalo en línea .Si lo configura
vm.overcommit_memory=2, se comprometerá en exceso hasta el porcentaje de RAM física configurada envm.overcommit_ratio(el valor predeterminado es 50%).Esto no sobrevivirá a un reinicio. Para persistencia, ponga esto en el
/etc/sysctl.confarchivo:y ejecutar
sysctl -p. No es necesario reiniciar.fuente
Declaración totalmente no calificada: deshabilitar la sobrecarga de memoria es definitivamente "más seguro" que habilitarlo.
$ customer lo configuró en unos pocos cientos de servidores web y ayudó mucho con los problemas de estabilidad. Incluso hay un cheque de Nagios llamando al fuego realmente fuerte si alguna vez NO está deshabilitado.
Por otro lado, las personas podrían no considerar "seguro" que sus procesos se queden sin memoria cuando les gustaría comprometerse demasiado con un pequeño ram y nunca lo usarían realmente. (es decir, SAP sería un muy buen ejemplo)
Entonces, has vuelto a ver si mejora las cosas para ti. Como ya lo está investigando para deshacerse de los problemas relacionados, creo que podría ayudarlo.
(Sé que arriesgaré un voto negativo de alguna persona gruñona)
fuente
Estoy de acuerdo en que deshabilitar el exceso de compromiso es más seguro que habilitarlo en algunas circunstancias. Si el servidor ejecuta solo unos pocos trabajos de memoria grandes (como las 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 teniendo problemas después de que el asesino de OOM haya hecho su trabajo.
fuente