¿Por qué kswapd0 se ejecuta en una computadora sin intercambio?

Tengo un servidor en la nube con ~ 14G de RAM y sin intercambio. Sin embargo, ocasionalmente veo que kswapd0 ocupa algo de CPU cuando ejecuto top. ¿Por qué kswapd0 se estaría ejecutando si no hay espacio de intercambio para que lo administre?

Todavía tiene un proceso para verificar si hay algún intercambio. Para reducirlo, deberá configurar su intercambio :

edite "/etc/sysctl.conf" como root, luego cambie (o agregue)

vm.swappiness = 0

El espacio de intercambio solo se usa para datos que no están respaldados por ningún otro archivo. Los datos que se asignan desde otros archivos en el disco (como los programas ejecutables) todavía se intercambian a sus respectivos archivos, incluso si no tiene un dispositivo de intercambio.

Es un problema bien conocido que cuando Linux se queda sin memoria, puede entrar en bucles de intercambio en lugar de hacer lo que debería estar haciendo, eliminando procesos para liberar RAM. Hay un asesino OOM (sin memoria) que hace esto, pero solo si Swap y RAM están llenos.

Sin embargo, esto no debería ser realmente un problema. Si hay un montón de procesos ofensivos, por ejemplo, Firefox y Chrome, cada uno con pestañas que usan y capturan memoria, entonces estos procesos provocarán la lectura de intercambio. Linux luego entra en un bucle donde la misma memoria se mueve de un lado a otro entre la memoria y el disco duro. Esto a su vez causa una inversión de prioridad donde el intercambio de algunos procesos de un lado a otro hace que el sistema no responda.

Si deshabilita el intercambio, empeora este problema ya que kswapd0 ahora no tiene otra opción que intercambiar la memoria asignada, como los ejecutables. Si intercambia ejecutables, es aún más probable que se vuelvan a intercambiar rápidamente.

Intenté activar este comportamiento en NetBSD para realizar pruebas y lo que sucedió allí es que el proceso ofensivo se volvió increíblemente lento mientras el sistema operativo en sí era muy receptivo. Lo que significa que el problema de intercambio ocurre pero no hay inversión de prioridad. Sin embargo, NetBSD no tiene controladores AMDGPU, por lo que me estoy quedando con Linux por el momento. Quizás NetBSD no ejecuta mapas de memoria ejecutables y es por eso que no ingresa bucles de intercambio, pero realmente no sé lo suficiente sobre su implementación para decir por qué no deja de responder.

Facebook también tuvo este problema y creó el OOMD, que es el demonio sin memoria. Este es un demonio que detecta la actividad de kswapd0 y comienza a matar procesos. Y según Facebook, esto eliminó casi por completo el problema de que los servidores Linux dejaran de responder. Sin embargo, no lo he probado y no sé qué tan bien funcionará en otros servidores o computadoras de escritorio / portátiles. De manera atractiva, OOMD tiene cierta lógica para decidir qué procesos matar primero para preservar los procesos del sistema y la parte de su sistema de servidor que es responsable de relanzar todo lo que se mató.

Sin embargo, no es así como debería resolverse. OOMD es un HACK feo. La solución real es arreglar la inversión de prioridad que causa un bucle de intercambio, así como hacer que el OOM Killer del núcleo sea más agresivo para eliminar procesos y liberar memoria. La solución pertenece al núcleo porque ese es el único lugar donde podemos estar seguros de que el problema se detecta a tiempo y los procesos se eliminan correctamente.

Establecer swappiness = 0 no es una solución porque cuando el sistema no tiene RAM libre, comienza a cambiar sin importar qué. No hay opción para garantizar que el sistema no comience a intercambiarse.

Y también arreglar las aplicaciones ofensivas no es una solución. Especialmente no si un usuario quiere explotar este error para que el sistema operativo no responda intencionalmente. Ser receptivo es responsabilidad del núcleo. Si Firefox no responde, entonces la solución es para la aplicación. Sin embargo, no solo deja de responder, sino que hace que todo el sistema operativo se vuelva muy lento y no responda. Al nivel que puede tomar media hora para iniciar sesión en SSH. El SSH no tiene nada que ver y si no se ejecuta, es un error en el núcleo, no en ninguna otra parte del sistema. Y no es un error, son dos errores. Un error es la inversión de prioridad donde se permite que un ciclo de intercambio fuera de rieles interfiera con otros procesos que no sean los procesos ofensivos y eso en sí mismo es malo. El otro error es que no No detecta que está en un bucle de intercambio y que causa un desgaste loco en el HDD / SSD o cualquier almacenamiento que respalde el intercambio. Al intercambiar ejecutables, esto no es un problema, ya que son solo mapas de memoria de lectura que no se vuelven a escribir en los discos, pero kswapd0 aún se bloquea al leer lo que al mismo tiempo se borra de la memoria.

Ah, y hay un tercer error. El hecho de que no hay forma de proteger el disco CACHE de ser comido cuando las aplicaciones con mucha memoria tragan toda la memoria disponible. Esta es una de las razones por las que kswapd0 hace que el sistema no responda. Los datos mapeados de la memoria más activa generalmente se almacenan en la memoria caché del disco, pero cuando Firefox se ha comido esa memoria caché, obviamente significa que tendrán que producirse lecturas del disco.

No necesariamente Firefox está causando el problema, pero es el navegador predeterminado, no Chrome. Y se sabe que ambos desencadenan este problema, ya que tratan la memoria disponible como algo que se desperdicia, incluida la memoria caché e intercambio que en Linux cuenta como "memoria disponible". Entonces, para no perder la "memoria disponible", úsela para el almacenamiento en caché y otras cosas. Obviamente, usar SWAP para DISK CACHE es una IDEA MUY MALA, pero los compañeros de Firefox y Chrome responden a eso con "memoria libre es memoria desperdiciada".

Entonces, lo que tenemos aquí son tres errores del núcleo que el equipo del núcleo no parece considerar errores. Y un error en Firefox, Chrome y todos los derivados que no consideran un error. Intenté construir Firefox en mi computadora portátil Fedora para investigar este problema y quizás parchearlo. Adivina qué. Construir Firefox con GCC en una CPU de 4 núcleos con 4 GB de RAM desencadena un SWAP LOOP con INVERSIÓN PRIORITARIA. Entonces, una de las aplicaciones que debe reescribirse es GCC. En NetBSD, lo que sucede es que solo las 4 instancias en ejecución de GCC se vuelven más lentas que ejecutar una instancia, pero no congela el sistema.

Sí, esto es un poco alocado, pero espero que aclare el problema actual con los subsistemas de memoria de Linux, así como las aplicaciones que lo causan.

Si no tiene intercambio y se kswapd0está ejecutando, su sistema está utilizando casi toda la RAM en ese momento. Es hora de obtener mejores herramientas para monitorear el uso de la memoria (o memoria libre / disponible en el sistema).

La solución real es reducir el uso de memoria (ejecutar procesos con menos pérdidas de memoria, ejecutar menos procesos, omitir la ejecución de algunos procesos, limitar el número de procesos hijos / trabajadores de algún software de servidor) u obtener más RAM. Si la necesidad de RAM se debe a pérdidas de memoria, puede optar por usar el intercambio. Linux debería ser bastante inteligente haciendo que las partes filtradas se intercambien con el tiempo suficiente. Tener un intercambio es mejor que nada, pero eso no es un sustituto real de tener la cantidad adecuada de RAM.