Durante años, el asesino OOM de mi sistema operativo no funciona correctamente y conduce a un sistema congelado.
Cuando el uso de la memoria es muy alto, todo el sistema tiende a "congelarse" (de hecho:se vuelve extremadamente lento) durante horas o incluso días , en lugar de matar procesos para liberar la memoria.
Lo máximo que he registrado son 7 días antes de resignarme a operar un reset.
Cuando está a punto de alcanzarse OOM, el iowait es muy, muy alto (~ 70 %), antes de volverse inconmensurable.
La herramienta:iotop ha demostrado que todos los programas están leyendo a un rendimiento muy alto (por decenas de MB/seg) desde mi disco duro.
¿Qué están leyendo esos programas?
– ¿La jerarquía de directorios?
– El código ejecutable en sí?
No exactamente ahora.
[editado] En el momento en que escribí este mensaje (en 2017) estaba usando un ArchLinux actualizado (4.9.27-1-lts), pero ya había experimentado el problema años antes.
He experimentado el mismo problema con varias distribuciones de Linux y diferentes configuraciones de hardware.
Actualmente (2019), estoy usando una versión actualizada de Debian 9.6 (4.9.0)
Tengo 16 GB de ram física, un SSD en el que está instalado mi sistema operativo, y no cualquier intercambio partición.
Debido a la cantidad de RAM que tengo, no quiero habilitar una partición de intercambio, ya que solo retrasaría la aparición del problema.
Además, con el intercambio de SSD con demasiada frecuencia, podría reducir la vida útil del disk.
Por cierto, ya he probado con y sin partición swap, ha demostrado que solo retrasa la aparición del problema, pero no siendo la solución.
Para mí, el problema se debe al hecho de que Linux elimina datos esenciales de los cachés. , lo que conduce a un sistema congelado porque tiene que leer todo, siempre desde el disco duro.
Incluso me pregunto si Linux no eliminaría las páginas de códigos ejecutables de los programas en ejecución, lo que explicaría por qué los programas que normalmente no leen muchos datos se comportan de esta manera en esta situación.
Probé varias cosas con la esperanza de solucionar este problema.
Una fue configurar /proc/sys/vm/min_free_kbytes a 1000000 (1 GB).
Porque este 1 GB debería permanecer libre, pensé que esta memoria estaría reservada por Linux para almacenar en caché datos importantes.
Pero no ha funcionado.
Además, creo útil agregar que, aunque podría sonar genial en teoría, restringir el tamaño de la memoria virtual al tamaño de la memoria física, definiendo /proc/sys/vm/overcommit_memory a 2 no es técnicamente posible decentemente en mi situación, porque el tipo de aplicaciones que uso requieren más memoria virtual de la que usan efectivamente por algunas razones.
Según el archivo /proc/meminfo , el Commited_AS el valor suele ser mayor que el doble de la RAM física de mi sistema (16 GB, Commited_AS suele ser> 32 GB).
He experimentado este problema con /proc/sys/vm/overcommit_memory a su valor predeterminado: , y durante un tiempo lo he definido como:1 , porque prefería que los programas fueran eliminados por el OOM killer en lugar de comportarse incorrectamente porque no verifican los valores de retorno de malloc cuando las asignaciones son rechazadas.
Cuando estaba hablando de este tema en IRC , he conocido a otros usuarios de Linux que han experimentado este mismo problema, así que supongo que muchos usuarios están preocupados por esto.
Para mí, esto no es aceptable ya que incluso Windows maneja mejor el uso elevado de memoria.
Si necesita más información, tiene una sugerencia, por favor dígame.
Documentación:
https://en.wikipedia.org/wiki/Thrashing_%28computer_science%29
https://en.wikipedia.org/wiki/Memory_overcommitment
https://www. kernel.org/doc/Documentation/sysctl/vm.txt
https://www.kernel.org/doc/Documentation/vm/overcommit-accounting
https://lwn.net/Articles/ 317814/
Ellos hablan de ello:
¿Por qué el asesino de memoria insuficiente (OOM) de Linux no se ejecuta automáticamente, sino que funciona con sysrq-key?
¿Por qué el asesino de OOM a veces no puede matar a los acaparadores de recursos?
Precargar OOM Killer
¿Es posible activar OOM-killer en un intercambio forzado?
¿Cómo evitar una alta latencia cerca de una situación OOM?
https://lwn.net/Articles/104179 /
https://bbs.archlinux.org/viewtopic.php?id=233843
Respuesta aceptada:
He encontrado dos explicaciones (de lo mismo) de por qué kswapd0 lo hace la lectura constante del disco ocurre mucho antes de que OOM-killer elimine el proceso infractor:
- ver la respuesta y el comentario de esta respuesta de askubuntu SE
- ver la respuesta y los comentarios de David Schwartz de esta respuesta en unix SE
Citaré aquí el comentario de 1. que realmente me abrió los ojos sobre por qué estaba recibiendo lecturas constantes del disco mientras todo estaba congelado:
Por ejemplo, considere un caso en el que no tiene swap y el sistema
casi se está quedando sin RAM. El núcleo tomará memoria de, por ejemplo,
Firefox (puede hacer esto porque Firefox está ejecutando un código ejecutable
que se ha cargado desde el disco; el código se puede cargar desde el disco
nuevamente si es necesario). Si Firefox necesita acceder a esa RAM nuevamente N
segundos después, la CPU genera una "falla grave" que obliga a Linux a
liberar RAM (por ejemplo, tomar algo de RAM de otro proceso), cargar el
datos faltantes del disco y luego permita que Firefox continúe como de costumbre.
Esto es bastante similar al intercambio normal y kswapd0 lo hace. – Mikko
Rantalainen 15 de febrero a las 13:08
Si alguien sabe cómo deshabilitar este comportamiento (¿tal vez volver a compilar el kernel con qué opciones?), ¡hágamelo saber lo antes posible! ¡Muy apreciado, gracias!
ACTUALIZACIÓN: La única forma que he encontrado hasta ahora es parcheando el kernel, y funciona para mí con el intercambio deshabilitado (es decir, CONFIG_SWAP is not set ) pero parece que no funciona para otros con intercambio habilitado; vea el parche dentro de esta pregunta.