Pregunta ¿Por qué kswapd usa una CPU alta en un sistema inactivo?


Tengo un sistema inactivo centOS de Linux y, sin embargo, kswapd utiliza 100% de CPU.

Todo lo que tengo en ejecución es una única sesión de bash con la mejor ejecución ... Tengo 32G de RAM y, sin embargo, kswapd usa constantemente el 100% de la CPU por más de 4 horas.


5
2017-09-29 19:53


origen


¿Podemos obtener la salida de top y ps -ef? Además, una salida de / proc / cpuinfo sería agradable. - Rilindo
posible duplicado de ¿Cómo puedo saber qué proceso está causando que kswapd esté en uso? - mailq
¿Qué versión de kernel tienes? Y puedes pegar la salida de free? - David Schwartz
Linux versión 2.6.18-164.el5 (mockbuild@builder10.centos.org) (gcc versión 4.1.2 20080704 (Red Hat 4.1.2-46)) # 1 SMP Thu Sep 3 03:28:30 EDT 2009 - Deshawn
Algo, aparte del caché, está usando la mayor parte de tu memoria. Necesitas averiguar qué. Tratar ps axv --sort=-rss | head -10 y mira el RSS campos. - David Schwartz


Respuestas:


AFAICS esto no está relacionado con RAM libre ni SWAP. Aquí tenemos el mismo problema que a veces afecta a las máquinas de producción y hay un montón de RAM libre, a menudo más de 700 MB sin buffers sucios para sincronizar y 0 bytes de SWAP utilizados. Definitivamente parece un error grave de Kernel debido a una condición de raza desconocida.

Actualmente ejecutamos CentOS Kernel 2.6.18-194.el5 y trataremos de reemplazarlo por un kernel más nuevo, porque pensamos que esto podría ayudar.

Actualizar:

RedHat había confirmado que es un problema del kernel para 2.6.18-194.el5

Soluciones:

Minimum: kernel-2.6.18-194.32.1.el5 contains the immediate bugfix
Better: kernel-2.6.18-238.el5 contains additional kswapd-related bugfixes
Best: kernel-2.6.18-348.4.1.el5 latest kernel which runs with RHEL 5.5 without change

Mientras tanto hay un guion, que es capaz de detectar la situación del 100% de la CPU bastante bien. Es llamado por nuestro monitoreo cada minuto para informarnos sobre la situación. Si la situación se prolonga demasiado tiempo, las máquinas afectadas se bloquearían por completo debido a que cada vez se procesan más procesos que no se pueden destruir con un 100% de CPU, hasta que la máquina se vuelve completamente inmanejable.

Actualmente, la única forma conocida para resolver el problema es reiniciar manualmente la máquina afectada. /sbin/reboot falla, porque la máquina se cuelga en apagado muy a menudo.

Para reiniciar con fuerza una máquina desde cualquier línea de comandos de shell raíz sin acceso directo a la consola, haga lo siguiente:

echo 10 > /proc/sys/kernel/panic
echo 1 > /proc/sys/kernel/sysrq
echo s > /proc/sysrq-trigger
sleep 5
echo s > /proc/sysrq-trigger
sleep 1
echo b > /proc/sysrq-trigger

Tenga en cuenta que haga esto después de desactivar la máquina, de modo que no haya más procesos de escritura en los discos. Esto evitará que fsck se ejecuta en graves problemas después de reiniciar.

Lo sentimos, no hay una solución real, pero HTH. Y tenga en cuenta que quizás haya otras cosas que causen una situación de CPU del 100% en kswapd que las que se describen aquí. Así que automatizar un reinicio en este caso tal vez sea una mala idea.


3
2018-03-28 16:16



Tenga en cuenta que el kswap que cuelga al 100% se confirmó como un error de Linux. Se fijó a mediados / finales de 2012 núcleos. - Tino
¿Tiene un enlace a qué versiones lo tiene y de qué versión está arreglado? - Wim Deblauwe
Todo lo que tengo es del enlace que está en mi post: 2.6.18-194.el5 (RHEL) se ve afectado, 2.6.18-194.32.1.el5 y lo de arriba es fijo. No tengo idea para otras series de kernel, lo siento. - Tino
Err, estoy usando Linux 4.0, y estoy teniendo este problema. - Zaz
Estoy viendo esta mierda en 4.2.x en la última versión de Xubuntu 15.10. Increíble, esto sigue siendo un problema en un sistema operativo supuestamente "serio" como Linux hoy ........ - lnostdal