Oom

configuración por defecto oom_killer, la memoria se puede utilizar cuando no hay consumo, pero a la memoria, oom_killer núcleo de Linux (de asesino en la memoria) programa explorará de nuevo tomar la mayor cantidad de memoria (puede haber más), y poner fin a su Suéltalo De hecho, el costo de esta exploración se sigue cada vez más grande, se puede optar por no dejar que oom_killer escaneada con el proceso más memoria, sólo para deshacerse de los procesos de memoria de la aplicación: sysctl -w vm.oom_kill_allocating_task = 1 Utilice esta configuración, oom_killer no va a pasar Es hora de encontrar el proceso que ocupa la mayor cantidad de memoria para matar, los programas de memoria grandes tienen la oportunidad de sobrevivir. Pero en el momento en que la memoria se agote, quienquiera que solicite o use una memoria en blanco será una tragedia, y puede ser que varios procesos se maten juntos, llenos de imprevisibilidad (por ejemplo, Xorg muere, por lo que Muchos programas se cuelgan juntos, y el mysqld en segundo plano será inconveniente si se elimina. Tampoco evita que pdflush destelle en el último minuto. En resumen, oom_killer es muy descoordinado, es mejor no dejarlo jugar. En este punto, openSolaris parece hacer un mejor trabajo. Desde el exterior, cuando la memoria no es suficiente, el sistema no anulará activamente el programa en ejecución, pero se negará a ejecutar el nuevo programa, y ​​si el programa en ejecución se está ejecutando, La solicitud de memoria se suspenderá hasta que haya memoria disponible. Compromiso excesivo Entonces, ¿por qué el sistema no puede detectar que la memoria se está agotando antes, es probable que malloc devuelva NULL? Ahora
sistema operativo, permitiendo memoria de la aplicación excesiva, aunque sólo sea por la memoria y el uso práctico, se puede aplicar a muchos espacio más grande que la memoria real (como el uso de malloc para la memoria, mientras que (1) malloc (x); un programa de este tipo puede ejecutarse durante mucho tiempo), solo una vez que se comenzó a usar (como rellenar con memset), se cuenta en el uso de memoria real, luego, si la memoria no es suficiente, entonces oom_killer se reproducirá. Actualmente, Linux ofrece algunas opciones para ajustar esta estrategia de memoria :-)

De forma predeterminada, vm.overcommit_memory = 0, esta vez puede solicitar más memoria, pero aún en un momento determinado La aplicación falló.

Hay más indulgencia, si vm.overcommit_memory = 1, todo malloc tendrá éxito incondicionalmente en un mundo terrible.

Esta es la última opción: sysctl -w vm.overcommit_memory = 2 este tiempo, hay limitaciones estrictas sobre la cantidad total de memoria de la aplicación, malloc devolverá un valor nulo cuando se supera el límite, la aplicación puede manejar adecuadamente este En este caso, oom_killer nunca volverá a salir, pdflush no permitirá que el disco duro gire, el sistema no responde, si un programa no puede manejar esta situación correctamente, se bloqueará de inmediato, quedará limpio y ordenado.

Pero esto también tiene algunas desventajas. En este momento, el parámetro vm.overcommit_ratio también funcionará. El valor predeterminado es 50, lo que significa que solo se puede asignar al 50% de la memoria física real. Si no hay un área de intercambio, la configuración de overcommit_ratio es pequeña y será muy trágica, casi nada se puede hacer. Entonces ponlo a 100, ¿las cosas son muy armoniosas? No es tan simple, el límite aquí es el límite en el número total de aplicaciones para la memoria. Si la aplicación no se usa realmente, se cuenta en el total. En este caso, la memoria real no está agotada, es probable que el programa no pueda solicitar memoria y se pierda algo de memoria. Aunque overcommit_ratio se puede configurar para que sea mayor que el número 100, pero al final establecer el número es realmente un problema difícil, establecer el grande, activada y no hay límite en cuanto la memoria cuando se quede sin disco duro será a su vez una locura, el sistema se congela durante algún tiempo, oom_killer tiene se podría personajes, un conjunto pequeño, y puede haber cientos de megabytes de memoria se pierde la memoria comprobar la información véase:

% cat /proc /meminfo

MemTotal: 2064616 kB

MemFree: 1556672 kB

…

CommitLimit:. 2064616 kB

Committed_AS:. 769068 kB

…

donde Committed_AS es la suma de la memoria solicitada por el programa y no puede exceder de CommitLimit.

Es obvio que Committed_AS + MemFree es más grande que MemTotal, y parece apropiado establecer CommitLimit en Committed_AS + MemFree.