Sección 9.6 "de Sobreasignación y OOM" en el doc que @dunxd menciona es especialmente gráfico sobre los peligros de permitir que de sobreasignación. Sin embargo, el 80 parecía interesante para mí, así que he realizado un par de pruebas.
Lo que he encontrado es que el overcommit_ratio afecta a la cantidad total de RAM disponible para TODOS los procesos. Los procesos de root, no parecen ser tratadas de manera diferente a los normales procesos de usuario.
Ajuste de la relación de a 100 o menos) debe proporcionar el clásico de la semántica, donde los valores de retorno de malloc/sbrk son fiables. La configuración de proporciones inferiores a 100 podría ser una manera de reservar más memoria RAM para que no se procesan actividades como el almacenamiento en caché y así sucesivamente.
Así que, en mi equipo con 24 Gb de RAM, con el swap desactivado, 9 GiB en uso, con top mostrando
Mem: 24683652k total, 9207532k used, 15476120k free, 19668k buffers
Swap: 0k total, 0k used, 0k free, 241804k cached
Aquí están algunos overcommit_ratio configuración y la cantidad de RAM que mi ram-consumidor programa podría agarrar (tocar cada página) - en cada caso, el programa salió limpiamente una vez malloc error.
50 ~680 MiB
60 ~2900 MiB
70 ~5200 MiB
100 ~12000 MiB
La ejecución de varias a la vez, incluso con algunos como el usuario root, no cambia la cantidad total que consumen juntos. Es interesante que no era capaz de consumir los últimos 3+ GiB o, lo free no caer muy por debajo de lo que se muestra aquí:
Mem: 24683652k total, 20968212k used, 3715440k free, 20828k buffers
Los experimentos fueron desordenado - nada que usa malloc en el momento en que todos RAM está en uso tiende a bloquearse, ya que muchos programadores son terribles acerca de la comprobación de malloc fallas en C, algunos populares de la colección de las bibliotecas de ignorarlo por completo, y C++, y varios otros idiomas, son aún peores.
La mayoría de las primeras implementaciones de los imaginarios de RAM que vi fueron para manejar un caso específico, donde un solo gran proceso - decir el 51%+ de memoria disponible necesaria para fork() para exec() algún programa de apoyo, generalmente, mucho más pequeña. Sistemas operativos con copy-on-write semántica permitiría a la fork(), pero con la salvedad de que si la horquilla proceso que en realidad se trató de modificar demasiadas páginas de memoria (cada uno de los cuales habrá que crear una instancia como una nueva página independiente de la inicial enorme proceso) que acabaría muriendo. El proceso padre estaba en peligro si asigna más memoria, y puede manejar, en algunos casos solo por esperar un poco para algún otro proceso de morir, y luego continuar. El proceso hijo generalmente acaba de reemplazar a sí mismo con un (normalmente más pequeñas) del programa a través de la exec() y fue entonces libre de la condición.
Linux de sobreasignación concepto es un enfoque extremo que permite tanto el fork() a ocurrir, así como permitir que los procesos únicos de forma masiva overallocate. OOM killer-causado muertes ocurren de forma asincrónica, incluso a los programas que hacen de la manija de la asignación de memoria de forma responsable. Yo personalmente odio de todo el sistema de sobreasignación en general y el oom killer en particular -, se fomenta un diablo de mayo de enfoque de la atención a la gestión de la memoria que infecta a las bibliotecas y a través de ellos cada aplicación que los utiliza.
Yo sugeriría que la configuración de la relación de a 100, y tener una partición swap, así que generalmente sólo terminan siendo utilizado por grandes procesos - que a menudo son sólo utilizar una pequeña fracción de la parte de sí que se pone a macerar en swap, y así proteger la gran mayoría de los procesos desde el OOM killer misfeature. Esto debería mantener su servidor web seguro de muerte al azar, y si fue escrito para manejar malloc de forma responsable, segura, incluso de matar a sí mismo (pero no apostaría por la segunda).
Eso significa que yo estoy usando esto en /etc/sysctl.d/10-no-overcommit.conf
vm.overcommit_memory = 2
vm.overcommit_ratio = 100
