Pics sur load average et IO Wait

28 réponses

Page 1 2

Auteur	Message
adesyf \| Membre Inscrit le : 24/06/2013	# Le 24/06/2013 à 17:56 Bonjour, J'ai un petit soucis avec la charge de mon serveur dédié (chez OVH). Régulièrement aux heures rondes xx:00 (mais pas à toutes les heures non plus), j'ai des pics sur le load average (ça monte jusque 7-8 et puis ça redescend). Ces pics s'accompagnent la plupart du temps de pics en IO Wait (pour le CPU). Avec htop au moment des pics, j'ai certaines commandes /usr/sbin/httpd -k start -DSSL qui sont en "D". Je n'ai pas de tâches cron qui tournent à heure fixe, ni de récupération de données qui vient de l'extérieur à heure fixe. Je ne suis pas expert sur l'administration de serveurs. Alors si quelqu'un pouvait m'orienter...... Merci d'avance Gérant de la société Dauran, éditeur de site internet et d'applications mobiles
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 24/06/2013 à 18:19 Hello, pour faire simple : beaucoup d'IOWait = le disque ne suit plus. Tu peux en savoir plus avec un «iostat -N 10 -kx» par exemple, que tu laisses tourner 2 minutes en heure de pointe. Si c'est un problème de lecture, il "suffit" d'ajouter de la mémoire. Si c'est un problème d'écriture, éventuellement voir du coté des SSD. Si ça ne suffit pas → faut creuser. daevel : infogérance et conseil \|\| moi
Rano \| Jean Modérateur Inscrit le : 13/04/2005	# Le 24/06/2013 à 18:23 Pour les crons, tu as vérifié celles des dossiers : /etc/cron.d /etc/cron.daily /etc/cron.hourly /etc/cron.monthly /etc/cron.weekly et le fichier /etc/crontab ? Par exemple dans /etc/crontab, il y a le "rtm" d'ovh qui tourne toutes les minutes, mais derrière (avec la meme cron), il éxécute toutes les heures un truc plus lourd. Chambres d'hote tavel Séjours en provence Forum mariage
adesyf \| Yann Membre Inscrit le : 24/06/2013	# Le 25/06/2013 à 10:14 Merci Dans le crontab, j'ai effectivement le rtm qui tourne toutes les minutes mais je ne vois pas le truc plus lourd qui est executé. Et je ne vois pas non plus pourquoi les "trucs" d'ovh augmenterait la charge. Sinon qu'est-ce que je dois chercher quand je lance un "iostat -N 10 -kx"? Gérant de la société Dauran, éditeur de site internet et d'applications mobiles
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 25/06/2013 à 10:34 Pour iostat, rien de particulier : faudrait juste faire un copier/coller ici afin qu'on comprenne un peu mieux de quoi il retourne. daevel : infogérance et conseil \|\| moi
adesyf \| Yann Membre Inscrit le : 24/06/2013	# Le 25/06/2013 à 10:44 La commande IOstat est introuvable. Je ne l'ai que dans les plugin de MUNIN. Gérant de la société Dauran, éditeur de site internet et d'applications mobiles
Rano \| Jean Modérateur Inscrit le : 13/04/2005	# Le 25/06/2013 à 10:54 Chez moi le RTM faisait loadait quand il lancait des netstat, toutes les heures. Chambres d'hote tavel Séjours en provence Forum mariage
adesyf \| Yann Membre Inscrit le : 24/06/2013	# Le 25/06/2013 à 11:09 Ce n'est pas un peu redondant RTM et MUNIN? Comment on peut suspendre RTM et netstat? Gérant de la société Dauran, éditeur de site internet et d'applications mobiles
adesyf \| Yann Membre Inscrit le : 24/06/2013	# Le 25/06/2013 à 11:17 Voilà ce que j'obtiens quand je lance un lsof au moment des pics. Si quelqu'un peut m'aider à dépouiller tout ça ns302726.ovh.net:home# lsof -i tcp:80 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME httpd 10780 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 10780 apache 343u IPv6 332202088 0t0 TCP ns302726.ovh.net:http->5.52.199.153:51042 (ESTABLISHED) httpd 10783 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 10854 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 10919 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 10922 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 10923 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 10924 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 10927 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 10927 apache 343u IPv6 332201338 0t0 TCP ns302726.ovh.net:http->user198.c4.krsko.kabelnet.net:49445 (ESTABLISHED) httpd 10929 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 10930 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 11373 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 11374 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 11375 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 11377 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 11378 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 11379 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 11383 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 11384 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 11386 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 11389 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 11390 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 11391 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 11392 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 11396 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 11397 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 11399 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 11399 apache 343u IPv6 332202172 0t0 TCP ns302726.ovh.net:http->80-71-135-50.u.parknet.dk:51701 (FIN_WAIT2) httpd 11401 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 11402 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 11402 apache 343u IPv6 332202267 0t0 TCP ns302726.ovh.net:http->salesconsulting.ro:49903 (ESTABLISHED) httpd 11403 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 11404 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 11405 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 11406 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 11407 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 11408 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 11409 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 11411 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 11413 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 11414 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 11415 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 11416 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 11416 apache 343u IPv6 332202236 0t0 TCP ns302726.ovh.net:http->80.12.100.16:2919 (FIN_WAIT2) httpd 29997 root 4u IPv6 142106247 0t0 TCP :http (LISTEN) Et voilà ce que j'ai en temps normal : COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME httpd 12673 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 12673 apache 343u IPv6 332298146 0t0 TCP ns302726.ovh.net:http->host-166-50-230-24.midco.net:36359 (FIN_WAIT2) httpd 12675 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 12679 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 13165 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 13231 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 13233 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 13234 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 13236 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 13236 apache 343u IPv6 332298157 0t0 TCP ns302726.ovh.net:http->host-166-50-230-24.midco.net:20344 (ESTABLISHED) httpd 13237 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 13243 apache 4u IPv6 142106247 0t0 TCP :http (LISTEN) httpd 29997 root 4u IPv6 142106247 0t0 TCP :http (LISTEN) Gérant de la société Dauran, éditeur de site internet et d'applications mobiles
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 25/06/2013 à 11:41 adesyf a dit : La commande IOstat est introuvable. Je ne l'ai que dans les plugin de MUNIN. Essaye de l'installer alors. Sous Debian & Ubuntu on la trouve dans le paquet sysstat. Rano a dit : Chez moi le RTM faisait loadait quand il lancait des netstat, toutes les heures. +1 daevel : infogérance et conseil \|\| moi
adesyf \| Yann Membre Inscrit le : 24/06/2013	# Le 25/06/2013 à 15:35 J'ai l'impression tout de même que cela vient du nombre de process /usr/sbin/httpd et/ou de process /usr/local/mysql/bin/mysqld qui explose et qui fait monter le LA. Mais je ne sais pas pourquoi ce nombre augmente aux heures rondes Gérant de la société Dauran, éditeur de site internet et d'applications mobiles
MathieuC \| Mathieu Modérateur Inscrit le : 15/07/2005	# Le 25/06/2013 à 15:50 C'est le RTM qui fait un netstat un peu poussé uniquement toutes les heures. Quand tu commences a avoir pas mal de connections ouvertes avec tes visiteurs, le netstat rame pas mal et fait un pic de charge. Moi je fais ca sur mes serveurs : # On desactive les scripts trop gourmands de RTM chmod a-x /usr/local/rtm/scripts/hour/listen_ports.pl
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 25/06/2013 à 16:04 @adesyf : quand les disques saturent, MySQL ralenti, ce qui augmente mécaniquement le nombre de process HTTP... Et si le nombre de process MySQL & HTTP commence à consommer trop de mémoire, ça va swapper, ce qui va saturer les disques, etc. Bref, savoir ce qui est la cause du problème n'est pas forcément si simple. @MathieuC : ou sinon «mkfs» daevel : infogérance et conseil \|\| moi
adesyf \| Yann Membre Inscrit le : 24/06/2013	# Le 25/06/2013 à 16:13 Merci Je vais essayer la désactivation des scripts trop gourmands et je vous tiens au courant. mkfs, par contre Gérant de la société Dauran, éditeur de site internet et d'applications mobiles
Rano \| Jean Modérateur Inscrit le : 13/04/2005	# Le 25/06/2013 à 16:29 moi je dirais de désactiver totalement la cron RTM Chambres d'hote tavel Séjours en provence Forum mariage
adesyf \| Yann Membre Inscrit le : 24/06/2013	# Le 25/06/2013 à 17:22 Alors la désactivation via : # On desactive les scripts trop gourmands de RTM chmod a-x /usr/local/rtm/scripts/hour/listen_ports.pl ne suffit pas...... Pour désactiver tout RTM, je fais ça comment? Gérant de la société Dauran, éditeur de site internet et d'applications mobiles
adesyf \| Yann Membre Inscrit le : 24/06/2013	# Le 25/06/2013 à 21:43 Après avoir désactivé les tâches cron RTM, j'ai toujours les même anos aux heures rondes. Donc retour à la case départ..... Qu'est-ce qui peut donc faire que les disques saturent aux heures rondes, augmentant le nombre de processus httpd et mysqld et donc le load average? Je sais que ça fait un peu novice mais j'aimerais vraiment bien comprendre .... Gérant de la société Dauran, éditeur de site internet et d'applications mobiles
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 25/06/2013 à 23:10 On aura beau tourner autour de la voiture autant qu'on veut, tant qu'on ouvrira pas le capot difficile de répondre quoi que ce soit d'utile ;) Il faut faire par étape : tu dis que tu as beaucoup d'IOWait, c'est déjà un excellent point de départ. iostat te dira à quel point et quelles sont les disques/partitions concernées, tandis que iotop te dira quels process génèrent ces accès. À partir de là on pourra creuser un peu plus. daevel : infogérance et conseil \|\| moi
adesyf \| Yann Membre Inscrit le : 24/06/2013	# Le 26/06/2013 à 09:15 Voilà Linux 3.8.13-xxxx-grs-ipv6-64 avg-cpu: %user 3,61 Device: sda 9,58 sdb 9,56 md6 4,10 md5 9,19 md3 1,40 md1 0,43 avg-cpu: %user 3,61 Device: rrqm/s wrqm/s sda sdb md6 md5 md3 md1 avg-cpu: %user 0,72 Device: rrqm/s wrqm/s sda sdb md6 md5 md3 md1 avg-cpu: %user 7,91 Device: rrqm/s wrqm/s sda sdb md6 md5 md3 md1 avg-cpu: %user 2,13 Device: rrqm/s wrqm/s sda sdb md6 md5 md3 md1 avg-cpu: %user 2,04 Device: rrqm/s wrqm/s sda sdb md6 md5 md3 md1 le résultat de la commande iostat -N 10 -kx (ce n'est monté qu'4 sur le loadaverage ce coup-ci et je n'ai pas eu d'iowait): 26/06/2013 _x86_64_ (8 CPU) %nice %system %iowait %steal %idle 0,13 0,73 0,07 0,00 95,45 tps kB_read/s kB_wrtn/s kB_read kB_wrtn 41,03 191,17 116967551 545038560 40,94 191,17 116716653 545038560 0,00 97,63 2649 278341952 0,01 75,97 19957 216578456 0,00 8,11 1853 23125172 0,05 4,00 140779 11392672 %nice %system %iowait %steal %idle 0,13 0,73 0,07 0,00 95,45 r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util 0,01 7,54 0,65 8,93 41,03 191,18 48,50 0,08 8,15 9,33 8,06 0,47 0,45 0,01 7,54 0,63 8,93 40,94 191,18 48,54 0,09 9,61 6,71 9,82 0,60 0,57 0,00 0,00 0,00 4,09 0,00 97,63 47,68 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 9,19 0,01 75,97 16,53 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 1,40 0,00 8,11 11,55 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,01 0,42 0,05 4,00 18,98 0,00 0,00 0,00 0,00 0,00 0,00 %nice %system %iowait %steal %idle 0,00 0,19 0,00 0,00 99,09 r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 4,00 0,00 0,00 0,00 0,00 100,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 %nice %system %iowait %steal %idle 0,00 1,58 0,00 0,00 90,51 r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util 0,00 15,60 0,40 15,50 1,60 290,80 36,78 0,04 2,62 0,00 2,68 0,13 0,20 0,00 15,60 0,00 15,90 0,00 292,40 36,78 0,08 1502,21 0,00 1502,21 0,91 1,44 0,00 0,00 0,00 10,60 0,00 208,00 39,25 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 12,10 0,00 49,20 8,13 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 3,30 0,00 13,20 8,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 2,70 0,00 10,80 8,00 0,00 0,00 0,00 0,00 0,00 0,00 %nice %system %iowait %steal %idle 0,00 0,60 0,00 0,00 97,27 r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util 0,00 6,20 0,00 3,80 0,00 80,40 42,32 0,00 0,21 0,00 0,21 0,21 0,08 0,00 6,20 0,00 3,80 0,00 80,40 42,32 0,00 0,21 0,00 0,21 0,21 0,08 0,00 0,00 0,00 4,00 0,00 56,40 28,20 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 2,60 0,00 10,40 8,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,90 0,00 3,60 8,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,90 0,00 3,60 8,00 0,00 0,00 0,00 0,00 0,00 0,00 %nice %system %iowait %steal %idle 0,00 0,65 0,00 0,00 97,31 r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util 0,00 4,20 0,00 2,80 0,00 77,20 55,14 0,00 0,43 0,00 0,43 0,43 0,12 0,00 4,20 0,00 2,80 0,00 77,20 55,14 0,00 0,14 0,00 0,14 0,14 0,04 0,00 0,00 0,00 2,10 0,00 57,60 54,86 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 2,60 0,00 10,40 8,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,90 0,00 3,60 8,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 Gérant de la société Dauran, éditeur de site internet et d'applications mobiles
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 26/06/2013 à 10:40 Euh... tu n'as quasiment aucune activité ici. T'as juste un tout petit pic à 8% de CPU, ton IOWait est très faible. daevel : infogérance et conseil \|\| moi

Auteur

Message

Inscrit le : 24/06/2013

# Le 24/06/2013 à 17:56

Bonjour,

J'ai un petit soucis avec la charge de mon serveur dédié (chez OVH).
Régulièrement aux heures rondes xx:00 (mais pas à toutes les heures non plus), j'ai des pics sur le load average (ça monte jusque 7-8 et puis ça redescend). Ces pics s'accompagnent la plupart du temps de pics en IO Wait (pour le CPU).

Avec htop au moment des pics, j'ai certaines commandes /usr/sbin/httpd -k start -DSSL qui sont en "D".

Je n'ai pas de tâches cron qui tournent à heure fixe, ni de récupération de données qui vient de l'extérieur à heure fixe.

Je ne suis pas expert sur l'administration de serveurs. Alors si quelqu'un pouvait m'orienter......

Merci d'avance

Gérant de la société Dauran, éditeur de site internet et d'applications mobiles

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 24/06/2013 à 18:19

Hello,

pour faire simple : beaucoup d'IOWait = le disque ne suit plus.

Tu peux en savoir plus avec un «iostat -N 10 -kx» par exemple, que tu laisses tourner 2 minutes en heure de pointe.

Si c'est un problème de lecture, il "suffit" d'ajouter de la mémoire.
Si c'est un problème d'écriture, éventuellement voir du coté des SSD.

Si ça ne suffit pas → faut creuser.

daevel : infogérance et conseil || moi

Rano | Jean
Modérateur

Inscrit le : 13/04/2005

# Le 24/06/2013 à 18:23

Pour les crons, tu as vérifié celles des dossiers :
/etc/cron.d
/etc/cron.daily
/etc/cron.hourly
/etc/cron.monthly
/etc/cron.weekly

et le fichier
/etc/crontab ?

Par exemple dans /etc/crontab, il y a le "rtm" d'ovh qui tourne toutes les minutes, mais derrière (avec la meme cron), il éxécute toutes les heures un truc plus lourd.

Chambres d'hote tavel
Séjours en provence
Forum mariage

adesyf | Yann
Membre

Inscrit le : 24/06/2013

# Le 25/06/2013 à 10:14

Merci

Dans le crontab, j'ai effectivement le rtm qui tourne toutes les minutes mais je ne vois pas le truc plus lourd qui est executé. Et je ne vois pas non plus pourquoi les "trucs" d'ovh augmenterait la charge.

Sinon qu'est-ce que je dois chercher quand je lance un "iostat -N 10 -kx"?

Gérant de la société Dauran, éditeur de site internet et d'applications mobiles

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 25/06/2013 à 10:34

Pour iostat, rien de particulier : faudrait juste faire un copier/coller ici afin qu'on comprenne un peu mieux de quoi il retourne.

daevel : infogérance et conseil || moi

adesyf | Yann
Membre

Inscrit le : 24/06/2013

# Le 25/06/2013 à 10:44

La commande IOstat est introuvable. Je ne l'ai que dans les plugin de MUNIN.

Gérant de la société Dauran, éditeur de site internet et d'applications mobiles

Rano | Jean
Modérateur

Inscrit le : 13/04/2005

# Le 25/06/2013 à 10:54

Chez moi le RTM faisait loadait quand il lancait des netstat, toutes les heures.

Chambres d'hote tavel
Séjours en provence
Forum mariage

adesyf | Yann
Membre

Inscrit le : 24/06/2013

# Le 25/06/2013 à 11:09

Ce n'est pas un peu redondant RTM et MUNIN?

Comment on peut suspendre RTM et netstat?

Gérant de la société Dauran, éditeur de site internet et d'applications mobiles

adesyf | Yann
Membre

Inscrit le : 24/06/2013

# Le 25/06/2013 à 11:17

Voilà ce que j'obtiens quand je lance un lsof au moment des pics.
Si quelqu'un peut m'aider à dépouiller tout ça

ns302726.ovh.net:home# lsof -i tcp:80
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
httpd 10780 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 10780 apache 343u IPv6 332202088 0t0 TCP ns302726.ovh.net:http->5.52.199.153:51042 (ESTABLISHED)
httpd 10783 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 10854 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 10919 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 10922 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 10923 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 10924 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 10927 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 10927 apache 343u IPv6 332201338 0t0 TCP ns302726.ovh.net:http->user198.c4.krsko.kabelnet.net:49445 (ESTABLISHED)
httpd 10929 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 10930 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 11373 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 11374 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 11375 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 11377 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 11378 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 11379 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 11383 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 11384 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 11386 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 11389 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 11390 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 11391 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 11392 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 11396 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 11397 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 11399 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 11399 apache 343u IPv6 332202172 0t0 TCP ns302726.ovh.net:http->80-71-135-50.u.parknet.dk:51701 (FIN_WAIT2)
httpd 11401 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 11402 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 11402 apache 343u IPv6 332202267 0t0 TCP ns302726.ovh.net:http->salesconsulting.ro:49903 (ESTABLISHED)
httpd 11403 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 11404 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 11405 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 11406 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 11407 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 11408 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 11409 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 11411 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 11413 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 11414 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 11415 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 11416 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 11416 apache 343u IPv6 332202236 0t0 TCP ns302726.ovh.net:http->80.12.100.16:2919 (FIN_WAIT2)
httpd 29997 root 4u IPv6 142106247 0t0 TCP *:http (LISTEN)

Et voilà ce que j'ai en temps normal :
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
httpd 12673 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 12673 apache 343u IPv6 332298146 0t0 TCP ns302726.ovh.net:http->host-166-50-230-24.midco.net:36359 (FIN_WAIT2)
httpd 12675 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 12679 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 13165 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 13231 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 13233 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 13234 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 13236 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 13236 apache 343u IPv6 332298157 0t0 TCP ns302726.ovh.net:http->host-166-50-230-24.midco.net:20344 (ESTABLISHED)
httpd 13237 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 13243 apache 4u IPv6 142106247 0t0 TCP *:http (LISTEN)
httpd 29997 root 4u IPv6 142106247 0t0 TCP *:http (LISTEN)

Gérant de la société Dauran, éditeur de site internet et d'applications mobiles

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 25/06/2013 à 11:41

adesyf a dit :
La commande IOstat est introuvable. Je ne l'ai que dans les plugin de MUNIN.

Essaye de l'installer alors. Sous Debian & Ubuntu on la trouve dans le paquet sysstat.

Rano a dit :
Chez moi le RTM faisait loadait quand il lancait des netstat, toutes les heures.

daevel : infogérance et conseil || moi

adesyf | Yann
Membre

Inscrit le : 24/06/2013

# Le 25/06/2013 à 15:35

J'ai l'impression tout de même que cela vient du nombre de process /usr/sbin/httpd et/ou de process /usr/local/mysql/bin/mysqld qui explose et qui fait monter le LA.

Mais je ne sais pas pourquoi ce nombre augmente aux heures rondes

Gérant de la société Dauran, éditeur de site internet et d'applications mobiles

MathieuC | Mathieu
Modérateur

Inscrit le : 15/07/2005

# Le 25/06/2013 à 15:50

C'est le RTM qui fait un netstat un peu poussé uniquement toutes les heures.

Quand tu commences a avoir pas mal de connections ouvertes avec tes visiteurs, le netstat rame pas mal et fait un pic de charge.

Moi je fais ca sur mes serveurs :

# On desactive les scripts trop gourmands de RTM
chmod a-x /usr/local/rtm/scripts/hour/listen_ports.pl

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 25/06/2013 à 16:04

@adesyf : quand les disques saturent, MySQL ralenti, ce qui augmente mécaniquement le nombre de process HTTP...
Et si le nombre de process MySQL & HTTP commence à consommer trop de mémoire, ça va swapper, ce qui va saturer les disques, etc.

Bref, savoir ce qui est la cause du problème n'est pas forcément si simple.

@MathieuC : ou sinon «mkfs»

daevel : infogérance et conseil || moi

adesyf | Yann
Membre

Inscrit le : 24/06/2013

# Le 25/06/2013 à 16:13

Merci
Je vais essayer la désactivation des scripts trop gourmands et je vous tiens au courant.

mkfs, par contre

Gérant de la société Dauran, éditeur de site internet et d'applications mobiles

Rano | Jean
Modérateur

Inscrit le : 13/04/2005

# Le 25/06/2013 à 16:29

moi je dirais de désactiver totalement la cron RTM

Chambres d'hote tavel
Séjours en provence
Forum mariage

adesyf | Yann
Membre

Inscrit le : 24/06/2013

# Le 25/06/2013 à 17:22

Alors la désactivation via :
# On desactive les scripts trop gourmands de RTM
chmod a-x /usr/local/rtm/scripts/hour/listen_ports.pl

ne suffit pas......

Pour désactiver tout RTM, je fais ça comment?

Gérant de la société Dauran, éditeur de site internet et d'applications mobiles

adesyf | Yann
Membre

Inscrit le : 24/06/2013

# Le 25/06/2013 à 21:43

Après avoir désactivé les tâches cron RTM, j'ai toujours les même anos aux heures rondes.
Donc retour à la case départ.....

Qu'est-ce qui peut donc faire que les disques saturent aux heures rondes, augmentant le nombre de processus httpd et mysqld et donc le load average?

Je sais que ça fait un peu novice mais j'aimerais vraiment bien comprendre ....

Gérant de la société Dauran, éditeur de site internet et d'applications mobiles

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 25/06/2013 à 23:10

On aura beau tourner autour de la voiture autant qu'on veut, tant qu'on ouvrira pas le capot difficile de répondre quoi que ce soit d'utile ;)

Il faut faire par étape : tu dis que tu as beaucoup d'IOWait, c'est déjà un excellent point de départ. iostat te dira à quel point et quelles sont les disques/partitions concernées, tandis que iotop te dira quels process génèrent ces accès. À partir de là on pourra creuser un peu plus.

daevel : infogérance et conseil || moi

adesyf | Yann
Membre

Inscrit le : 24/06/2013

# Le 26/06/2013 à 09:15

Voilà
Linux 3.8.13-xxxx-grs-ipv6-64
avg-cpu: %user 3,61
Device: sda 9,58 sdb 9,56 md6 4,10 md5 9,19 md3 1,40 md1 0,43

avg-cpu: %user 3,61
Device: rrqm/s wrqm/s sda sdb md6 md5 md3 md1
avg-cpu: %user 0,72
Device: rrqm/s wrqm/s sda sdb md6 md5 md3 md1
avg-cpu: %user 7,91
Device: rrqm/s wrqm/s sda sdb md6 md5 md3 md1
avg-cpu: %user 2,13
Device: rrqm/s wrqm/s sda sdb md6 md5 md3 md1
avg-cpu: %user 2,04
Device: rrqm/s wrqm/s sda sdb md6 md5 md3 md1 le résultat de la commande iostat -N 10 -kx (ce n'est monté qu'4 sur le loadaverage ce coup-ci et je n'ai pas eu d'iowait):
26/06/2013 _x86_64_ (8 CPU)
%nice %system %iowait %steal %idle
0,13 0,73 0,07 0,00 95,45
tps kB_read/s kB_wrtn/s kB_read kB_wrtn
41,03 191,17 116967551 545038560
40,94 191,17 116716653 545038560
0,00 97,63 2649 278341952
0,01 75,97 19957 216578456
0,00 8,11 1853 23125172
0,05 4,00 140779 11392672
%nice %system %iowait %steal %idle
0,13 0,73 0,07 0,00 95,45
r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
0,01 7,54 0,65 8,93 41,03 191,18 48,50 0,08 8,15 9,33 8,06 0,47 0,45
0,01 7,54 0,63 8,93 40,94 191,18 48,54 0,09 9,61 6,71 9,82 0,60 0,57
0,00 0,00 0,00 4,09 0,00 97,63 47,68 0,00 0,00 0,00 0,00 0,00 0,00
0,00 0,00 0,00 9,19 0,01 75,97 16,53 0,00 0,00 0,00 0,00 0,00 0,00
0,00 0,00 0,00 1,40 0,00 8,11 11,55 0,00 0,00 0,00 0,00 0,00 0,00
0,00 0,00 0,01 0,42 0,05 4,00 18,98 0,00 0,00 0,00 0,00 0,00 0,00
%nice %system %iowait %steal %idle
0,00 0,19 0,00 0,00 99,09
r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
0,00 0,00 0,00 0,00 0,00 0,00 0,00 4,00 0,00 0,00 0,00 0,00 100,00
0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
%nice %system %iowait %steal %idle
0,00 1,58 0,00 0,00 90,51
r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
0,00 15,60 0,40 15,50 1,60 290,80 36,78 0,04 2,62 0,00 2,68 0,13 0,20
0,00 15,60 0,00 15,90 0,00 292,40 36,78 0,08 1502,21 0,00 1502,21 0,91 1,44
0,00 0,00 0,00 10,60 0,00 208,00 39,25 0,00 0,00 0,00 0,00 0,00 0,00
0,00 0,00 0,00 12,10 0,00 49,20 8,13 0,00 0,00 0,00 0,00 0,00 0,00
0,00 0,00 0,00 3,30 0,00 13,20 8,00 0,00 0,00 0,00 0,00 0,00 0,00
0,00 0,00 0,00 2,70 0,00 10,80 8,00 0,00 0,00 0,00 0,00 0,00 0,00
%nice %system %iowait %steal %idle
0,00 0,60 0,00 0,00 97,27
r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
0,00 6,20 0,00 3,80 0,00 80,40 42,32 0,00 0,21 0,00 0,21 0,21 0,08
0,00 6,20 0,00 3,80 0,00 80,40 42,32 0,00 0,21 0,00 0,21 0,21 0,08
0,00 0,00 0,00 4,00 0,00 56,40 28,20 0,00 0,00 0,00 0,00 0,00 0,00
0,00 0,00 0,00 2,60 0,00 10,40 8,00 0,00 0,00 0,00 0,00 0,00 0,00
0,00 0,00 0,00 0,90 0,00 3,60 8,00 0,00 0,00 0,00 0,00 0,00 0,00
0,00 0,00 0,00 0,90 0,00 3,60 8,00 0,00 0,00 0,00 0,00 0,00 0,00
%nice %system %iowait %steal %idle
0,00 0,65 0,00 0,00 97,31
r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
0,00 4,20 0,00 2,80 0,00 77,20 55,14 0,00 0,43 0,00 0,43 0,43 0,12
0,00 4,20 0,00 2,80 0,00 77,20 55,14 0,00 0,14 0,00 0,14 0,14 0,04
0,00 0,00 0,00 2,10 0,00 57,60 54,86 0,00 0,00 0,00 0,00 0,00 0,00
0,00 0,00 0,00 2,60 0,00 10,40 8,00 0,00 0,00 0,00 0,00 0,00 0,00
0,00 0,00 0,00 0,90 0,00 3,60 8,00 0,00 0,00 0,00 0,00 0,00 0,00
0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00

Gérant de la société Dauran, éditeur de site internet et d'applications mobiles

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 26/06/2013 à 10:40

Euh... tu n'as quasiment aucune activité ici. T'as juste un tout petit pic à 8% de CPU, ton IOWait est très faible.

daevel : infogérance et conseil || moi

Page 1 2

Répondre

Vous ne pouvez pas participer au forum, car votre inscription n'a pas été validée. Pour vous faire valider en tant que Membre, cliquez ici.