por que o kswapd está usando alta CPU em um sistema ocioso?

Question

Eu tenho um sistema ocioso Linux centOS e ainda o kswapd está usando 100% cpu.

Tudo o que tenho em execução é uma sessão bash única com o top running .... Eu tenho 32G RAM e ainda kswapd está constantemente usando 100% cpu por mais de 4 horas.

    

Answer 1

AFAICS isso não está relacionado à RAM livre nem ao SWAP. Temos o mesmo problema aqui, que às vezes atinge máquinas de produção e há muita RAM livre, muitas vezes mais de 700 MB sem buffers sujos para sincronizar e 0 bytes de SWAP usados. Parece definitivamente um bug do kernel severo devido a alguma condição desconhecida.

Atualmente, rodamos o CentOS Kernel 2.6.18-194.el5 e tentamos substituí-lo por algum kernel mais novo, porque achamos que isso pode ajudar.

Update:

RedHat had confirmed that it is a kernel issue for 2.6.18-194.el5

Solutions:

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

Enquanto isso, , há um script , que é capaz de detectar os 100% Situação da CPU muito bem. É chamado pelo nosso monitoramento a cada minuto para nos informar sobre a situação. Se a situação permanecer por muito tempo, as máquinas afetadas serão bloqueadas completamente devido a processos cada vez mais inutilizáveis usando 100% de CPU, até que a máquina se torne completamente incontrolável.

Atualmente, a única maneira conhecida de resolver o problema é reinicializar manualmente a máquina afetada. /sbin/reboot falha, porque a máquina trava no desligamento muitas vezes.

Para reinicializar a máquina a partir de qualquer linha de comando do shell root sem acesso direto ao Console do:

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

Lembre-se, faça isso depois de inativar a máquina, de modo que não haja mais processo gravando nos discos. Isso evitará que fsck seja executado com problemas sérios após a reinicialização.

Desculpe, nenhuma solução real, mas HTH. E lembre-se, talvez possa haver outras coisas que causam uma situação de 100% da CPU no kswapd do que o descrito aqui. Portanto, automatizar uma reinicialização nesse caso talvez seja uma má ideia.