Tuve un problema con un proceso que generaba muchos subprocesos debido a un error, que consumía memoria y provocaba intercambios intensos en la partición de intercambio. Por lo tanto, desactivé el intercambio (que de todos modos se recomienda en los clústeres de servidores) para permitir que el programa defectuoso falle antes de tiempo. Para mi sorpresa, ¡esto no mejoró las cosas en absoluto! Del mismo modo, establecerlo vm.swappinessen 0 no ayudó. iotoprevelado pesadolecturadesde el disco (casi sin escritura).
Sospecho que el kernel de Linux todavía está intercambiando páginas de códigos en la memoria y relee las páginas de códigos sobreescritas desde el disco cuando es necesario. Cuando la RAM es muy baja, esto sucede con mucha frecuencia, lo que provoca sacudidas y hace que la computadora casi no responda.
¿Cómo se puede prevenir esta situación desafortunada y potencialmente peligrosa? Intenté desactivar swap, cgroups para restricciones de memoria y CPU para ese proceso, y ulimit para máx. 30 procesos. Nada mejoró siquiera la situación. (Bueno, esto no es del todo cierto: un límite de RAM que dejó cientos de MB permanentemente sin usar ayudó).
En particular: ¿Puedo evitar el intercambio de segmentos de código en la memoria y dejar que el proceso de solicitud de RAM simplemente obtenga un NULL para su próximo malloc?
Respuesta1
¿Qué tal si ajustamos la contabilidad de sobrecompromiso de memoria y la configuramos en la opción 2 (no comprometer demasiado) en lugar de la opción predeterminada 0 (sobrecompromiso heurístico)? La descripción de eso dice
Don't overcommit. The total address space commit
for the system is not permitted to exceed swap + a
configurable amount (default is 50%) of physical RAM.
Depending on the amount you use, in most situations
this means a process will not be killed while accessing
pages but will receive errors on memory allocation as
appropriate.
El fragmento anterior es dedocumentación del núcleo
La política se puede establecer con vm.overcommitsintonizable.