Alta carga média de Iowait + alta em um servidor de monitoramento

Question

Eu tenho um servidor nagios que estava funcionando perfeitamente até alguns dias atrás. Eu parei e reiniciei para aumentar sua RAM, e desde então, o iowait aumentou dramaticamente no servidor (mais de 20%, era menos de 1% antes). Eu tentei colocar de volta a quantidade original de RAM no servidor, mas eu ainda recebo o mesmo problema. Eu li muitos problemas de iowait semelhantes no serverfault, mas nunca consegui encontrar a explicação no meu caso:
Olhando para o iotop, vejo que há muito io para pdflush, que está fazendo cache de página & kjournald, que é dedicado para arquivar o sistema de arquivos ext3. Eu não sei se é normal. De acordo com outras questões de falha de servidor, tentei colocar noatime no fstab. O sistema de arquivos Ext3 é montado com o modo de dados ordenados

Total DISK READ: 0.00 B/s | Total DISK WRITE: 210.44 K/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
  650 be/3 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [kjournald]
11482 be/4 root        0.00 B/s    0.00 B/s  0.00 % 98.42 % [pdflush]
12167 be/4 nagios      0.00 B/s    0.00 B/s  0.00 %  0.12 % nagios -d /srv/eyesofnetwork/nagios-3.4.1/etc/nagios.cfg
   11 rt/3 root        0.00 B/s    0.00 B/s  0.00 %  0.10 % [migration/3]
12168 be/4 nagios      0.00 B/s    0.00 B/s  0.02 %  0.08 % nagios -d /srv/eyesofnetwork/nagios-3.4.1/etc/nagios.cfg
12165 be/4 nagios      0.00 B/s    0.00 B/s 98.42 %  0.02 % nagios -d /srv/eyesofnetwork/nagios-3.4.1/etc/nagios.cfg
 2600 be/3 root        0.00 B/s    0.00 B/s  0.00 %  0.02 % auditd
12164 be/4 nagios      0.00 B/s    0.00 B/s  0.00 %  0.00 % nagios -d /srv/eyesofnetwork/nagios-3.4.1/etc/nagios.cfg
    8 rt/3 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [migration/2]
   20 rt/3 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [migration/6]
   26 be/3 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [events/0]
   23 rt/3 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [migration/7]
 3047 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % snmpd -Ln -Lf /dev/null -p /var/run/snmpd.pid -a
12169 be/4 nagios      0.00 B/s    0.00 B/s  0.12 %  0.00 % nagios -d /srv/eyesofnetwork/nagios-3.4.1/etc/nagios.cfg
   14 rt/3 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [migration/4]
 2601 be/3 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % auditd
    5 rt/3 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [migration/1]
   17 rt/3 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [migration/5]
 5228 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % bash
   10 rt/3 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [watchdog/2]
   13 rt/3 root        0.00 B/s    0.00 B/s  0.10 %  0.00 % [watchdog/3]

a seguinte linha

 12165 be/4 nagios      0.00 B/s    0.00 B/s 98.42 %  0.02 % nagios -d /srv/eyesofnetwork/nagios-3.4.1/etc/nagios.cfg

parece bastante surpreendente: como eu posso ter 98,42% de swapin desde que eu quase não tenho swap:

free -o
             total       used       free     shared    buffers     cached
Mem:       4046468    3163796     882672          0     103548    2193604
Swap:      4192956       1572    4191384

top não mostra algo específico, exceto alta carga e alta iowait

top - 10:07:56 up 12 days, 23:42,  4 users,  load average: 8.60, 9.29, 9.85
Tasks: 177 total,   1 running, 176 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.1%us,  0.0%sy,  0.0%ni, 77.2%id, 22.6%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   4046468k total,  3165500k used,   880968k free,   104204k buffers
Swap:  4192956k total,     1572k used,  4191384k free,  2201500k cached
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
 5246 root      15   0 14252 2632  836 R  0.3  0.1   0:03.94 top                
    1 root      15   0 10372  696  584 S  0.0  0.0   0:03.61 init               
    2 root      RT  -5     0    0    0 S  0.0  0.0   0:14.80 migration/0        
    3 root      34  19     0    0    0 S  0.0  0.0   0:00.73 ksoftirqd/0        
    4 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 watchdog/0         
    5 root      RT  -5     0    0    0 S  0.0  0.0   0:13.93 migration/1        
    6 root      34  19     0    0    0 S  0.0  0.0   0:01.75 ksoftirqd/1        
    7 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 watchdog/1         
    8 root      RT  -5     0    0    0 S  0.0  0.0   0:09.51 migration/2        
    9 root      34  19     0    0    0 S  0.0  0.0   0:01.09 ksoftirqd/2        
   10 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 watchdog/2         
   11 root      RT  -5     0    0    0 S  0.0  0.0   0:08.98 migration/3        
   12 root      34  19     0    0    0 S  0.0  0.0   0:01.46 ksoftirqd/3        
   13 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 watchdog/3         
   14 root      RT  -5     0    0    0 S  0.0  0.0   0:20.36 migration/4        
   15 root      34  19     0    0    0 S  0.0  0.0   0:01.15 ksoftirqd/4        
   16 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 watchdog/4         

desativar o processo nagios faz com que o sistema carregue normalmente (ou seja, < 1), mas eu ainda recebo alta iowait.

No topo, o DSK está 100% ocupado, mesmo sem o processo nagios em execução. Posso ter problemas no disco rígido? (é um verde digital ocidental, que não deveria estar rodando em tal servidor). Eu não recebo nenhuma mensagem especial no dmesg ou syslog.

    

Answer 1

Oh, me desculpe. Você está usando um disco WD Green para algo diferente de um PC de mesa?

Não.

Eles são lentos, não confiáveis (eles vão dormir e saem de uma matriz RAID) e são totalmente inadequados para o que você deseja fazer.

Se você estiver experimentando um alto IOWait, isso significa que o subsistema de disco não é capaz de lidar com a quantidade de E / S de disco necessária.

A maneira fácil de resolver isso é adicionar mais discos (idealmente um monte em um array RAID6).

Você também deve verificar a integridade geral do disco com o smartctl e fazer um backup (deve fazer isso regularmente de qualquer maneira, mas se você tiver um WD Green muito usado, eu ficaria muito cauteloso.)

    

Answer 2

use o comando swapoff e swapon para limpar o swap. Depois disso, pare os nagios e verifique se algum pid ainda em execução usa ps -ef|grep nagios agora, inicie os nagios mais uma vez.

O comando abaixo irá dizer qual partição o swap fs tem

swapon -s

swapoff /dev/sdaN

swapon /dev/sdaN