Puede que se de el caso de que halles algún fallo en tu código o proyecto, recuerda probar siempre en un ambiente de testing antes añadir el código al proyecto final.
Solución:
Solución 1:
Configuración overcommit_ratio a 80 probablemente no sea la acción correcta. Establecer el valor en un valor inferior a 100 casi siempre es incorrecto.
La razón de esto es que las aplicaciones de Linux asignan más de lo que realmente necesitan. Digamos que asignan 8 kb para almacenar un par de caracteres string de texto. Bueno, eso es varios KB sin usar allí mismo. Las aplicaciones hacen esto mucho, y para eso está diseñado el overcommit.
Básicamente, con un overcommit en 100, el kernel no permitirá que las aplicaciones asignen más memoria de la que tienes (swap + ram). Establecerlo en menos de 100 significa que nunca utilizará toda su memoria. Si va a establecer esta configuración, debe establecerla por encima de 100 debido al escenario mencionado anteriormente, que es bastante común.
Ahora, en cuanto a su problema con la activación del asesino de OOM, es probable que la configuración manual de overcommit no solucione esto. La configuración predeterminada (determinación heurística) es bastante inteligente.
Si desea ver si esta es realmente la causa del problema, consulte /proc/meminfo cuando el asesino de OOM corre. Si ves eso Committed_AS esta cerca de CommitLimit, pero free todavía muestra memoria libre disponible, entonces sí, puede ajustar manualmente el sobreasignación para su escenario. Establecer este valor demasiado bajo hará que el asesino de OOM comience a matar aplicaciones cuando todavía tenga mucha memoria libre. Establecerlo demasiado alto puede hacer que las aplicaciones aleatorias mueran cuando intentan usar la memoria que se les asignó, pero no está realmente disponible (cuando toda la memoria se agota).
Solucion 2:
La sección 9.6 “Overcommit y OOM” en el documento que menciona @dunxd es particularmente gráfica sobre los peligros de permitir overcommit. sin embargo, el 80 También me pareció interesante, así que realicé algunas pruebas.
Lo que encontré es que el overcommit_ratio afecta la RAM total disponible para TODOS los procesos. Los procesos raíz no parecen ser tratados de manera diferente a los procesos de usuario normales.
Establecer la relación en 100 o menos debería proporcionar la semántica clásica donde los valores de retorno de malloc/sbrk son fiables. Poniéndolo en proporciones más bajas que 100 podría ser una forma de reservar más RAM para actividades que no son de proceso, como el almacenamiento en caché, etc.
Entonces, en mi computadora con 24 GiB de RAM, con swap deshabilitado, 9 GiB en uso, con top demostración
Mem: 24683652k total, 9207532k used, 15476120k free, 19668k buffers
Swap: 0k total, 0k used, 0k free, 241804k cached
Aquí están algunas overcommit_ratio la configuración y la cantidad de RAM que mi programa consumidor de RAM podía tomar (tocando cada página); en cada caso, el programa salió limpiamente una vez malloc fallido.
50 ~680 MiB
60 ~2900 MiB
70 ~5200 MiB
100 ~12000 MiB
Ejecutar varios a la vez, incluso con algunos como usuario root, no cambió la cantidad total que consumieron juntos. Es interesante que no haya podido consumir los últimos 3+ GiB más o menos; los free no cayó mucho por debajo de lo que se muestra aquí:
Mem: 24683652k total, 20968212k used, 3715440k free, 20828k buffers
Los experimentos fueron desordenados: cualquier cosa que use malloc en el momento en que toda la RAM está en uso tiende a fallar, ya que muchos programadores son terribles para verificar fallas de malloc en C, algunas bibliotecas de colecciones populares lo ignoran por completo, y C ++ y varios otros lenguajes incluso lo son. peor.
La mayoría de las primeras implementaciones de RAM imaginaria que vi fueron para manejar un caso muy específico, donde un único proceso grande, digamos 51% + de la memoria disponible, necesitaba fork() con el fin de exec() algún programa de apoyo, generalmente uno mucho, mucho más pequeño. Los sistemas operativos con semántica de copia sobre escritura permitirían fork(), pero con la condición de que si el proceso bifurcado realmente intentara modificar demasiadas páginas de memoria (cada una de las cuales tendría que ser instanciada como una nueva página independiente del gran proceso inicial) terminaría siendo eliminada. El proceso padre solo estaba en peligro si se asignaba más memoria, y podía manejar el agotamiento, en algunos casos simplemente esperando un poco a que muriera algún otro proceso y luego continuando. El proceso hijo generalmente se reemplazó a sí mismo con un programa (generalmente más pequeño) a través de exec() y luego quedó libre de la salvedad.
El concepto de overcommit de Linux es un enfoque extremo para permitir tanto el fork() que ocurra, además de permitir que los procesos individuales se sobreasignen masivamente. Las muertes causadas por asesinos de OOM ocurren de forma asincrónica, incluso en programas que hacer manejar la asignación de memoria de manera responsable. Yo personalmente odio en todo el sistema overcommit en general y oom-killer en particular: fomenta un enfoque de gestión de la memoria que se preocupa por el diablo y que infecta las bibliotecas y, a través de ellas, todas las aplicaciones que las usan.
Sugeriría establecer la proporción en 100 y tener también una partición de intercambio que generalmente solo terminaría siendo utilizada por procesos enormes, que a menudo solo usan una pequeña fracción de la parte de sí mismos que se rellena en el intercambio, y por lo tanto proteger la gran mayoría de los procesos del error asesino de OOM. Esto debería mantener su servidor web a salvo de la muerte aleatoria y si fue escrito para manejar malloc responsablemente, incluso a salvo de suicidarse (pero no apueste por lo último).
Eso significa que estoy usando esto en /etc/sysctl.d/10-no-overcommit.conf
vm.overcommit_memory = 2
vm.overcommit_ratio = 100
Calificaciones y comentarios
Agradecemos que quieras asentar nuestra misión mostrando un comentario y valorándolo te estamos agradecidos.