1 votes

Iowait élevé + moyenne de charge élevée sur un serveur de surveillance

J'ai un serveur nagios qui fonctionnait parfaitement jusqu'à il y a quelques jours. Je l'ai arrêté et redémarré pour augmenter sa RAM, et depuis lors, l'iowait a augmenté de façon spectaculaire sur le serveur (plus de 20%, il était inférieur à 1% avant). J'ai essayé de remettre la quantité originale de RAM sur le serveur mais j'ai toujours le même problème.
J'ai lu beaucoup de problèmes iowait similaires sur serverfault, mais je n'ai jamais réussi à trouver l'explication dans mon cas :
En regardant iotop, je vois qu'il y a beaucoup d'io pour pdflush, qui fait du cache de page et kjournald, qui est dédié à la journalisation du système de fichiers ext3. Je ne sais pas si c'est normal. Selon d'autres questions sur serverfault, j'ai essayé de mettre noatime dans le fstab. Le système de fichiers Ext3 est monté avec un mode de données ordonné.

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]

la ligne suivante

 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

Cela semble assez surprenant : comment puis-je avoir 98,42% de swapin alors que je n'ai presque pas de swap :

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

le top ne montre pas quelque chose de spécifique, excepté une charge élevée et un iowait élevé.

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         

La désactivation du processus nagios rend la charge du système normale (i.e. < 1 ) mais j'ai toujours un iowait élevé.

En haut, le DSK est occupé à 100%, même si aucun processus nagios ne tourne. Peut-être ai-je un problème de disque dur ? (c'est un Western Digital Green, qui n'est pas censé fonctionner dans un tel serveur). Je ne reçois aucun message particulier sur dmesg ou syslog.

0 votes

Combien de disques ? un seul ?

0 votes

Oui, un seul, pas de raid.

2voto

Pablo Venturino Points 1660

Oh, je suis désolé. Utilisez-vous un disque WD Green pour autre chose qu'un PC de bureau ?

Ne le faites pas.

Ils sont lents, peu fiables (ils peuvent s'endormir et sortir d'une matrice RAID) et totalement inadaptés à ce que vous voulez faire.

Si vous rencontrez un IOWait élevé, cela signifie que le sous-système de disque n'est pas en mesure de gérer la quantité d'IO disque requise.

Le moyen le plus simple de résoudre ce problème est d'ajouter des disques supplémentaires (idéalement un ensemble de disques dans une matrice RAID6).

Vous devriez également vérifier la santé générale du disque avec smartctl, et faire une sauvegarde (vous devriez le faire régulièrement de toute façon, mais si vous avez un WD Green sur-utilisé, je serais très prudent).

0 votes

Les sauvegardes sont faites tous les jours, donc je suis assez confiant sur ce point. Mon problème est que je n'ai pas remarqué quelque chose d'anormal en faisant smartctl, aucune erreur, le nombre de cycles de charge n'augmente pas sans limites. J'ai déjà programmé l'échange de ce disque vert wd, mais je voudrais être sûr que c'est bien le cas. sólo l'origine du problème. (fyi Il n'y a pas de raid sur le serveur).

0 votes

Vous avez déjà essayé une restauration ? ;)

1 votes

Il n'y a jamais une seule origine d'un problème. Il y a toujours quelque chose qui n'est pas tout à fait parfait, mais les choses font rapidement boule de neige.

0voto

Sharad Chhetri Points 129

Utilisez les commandes swapoff et swapon pour effacer l'échange. Après cela, arrêtez nagios et vérifiez si un pid est toujours en cours d'exécution avec la commande ps -ef|grep nagios maintenant démarrez le nagios une fois de plus.

La commande suivante indiquera quelle partition le fs de swap possède

swapon -s

swapoff /dev/sdaN

swapon /dev/sdaN

0 votes

J'ai désactivé le swap, sans succès : j'ai toujours le même iowait, je vois toujours 99% de swapin (processus bash), je ne sais pas comment c'est possible.

0 votes

Arrêtez nagios et vérifiez avec iotop. Faites-nous savoir ce qui se passe maintenant. Quels sont les autres services qui tournent sur ce serveur ? Y a-t-il un montage nfs dans le serveur ?

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X