[Dédié] Lenteurs alors que tout paraît OK

[sietjp]

Bonjour,
J'aimerais avoir votre avis sur un problème de lenteur sur mon dédié (suite au crash de mon disque dur relaté ici : http://www.webrankinfo.com/forums/viewtopic_71086.htm )

Quand je charge un page, que j'uploade un fichier vi a ftp ou que je me connecte via la console SSH, il y a souvent un moment d'attente plus long que la normal (quelques secondes) avant que l'action soit traitée. Ca fait un peu comme si on travaillait sur un serveur surchargé, sauf que... il n'est pas surchargé du tout. Et puis pendant quelques minutes les pages se chargent à la vitesse de l lumière (normalement quoi).

J'ai lancé des tops et j'ai eu la surprise de voir que le load average montait de temps en temps à 5 pour edescendre quelques minute plus tard à 1 ! Rien ne permettait d'expliquer ceci, la conso CPU est satble, pas de SWAP, nombre de visiteur stable. Le site est trés boen optimisé au niveau des requêtes mysql, je logue toutes les requêtes au dessus de 1 s et corrige tout ça, de toutes manières je n'avais pas de problème avec ce même site avant le crash du disque dur et la réinstallation...

J'ai soulevé le problème au support et il s on détecté ue première fois une mamuvaise config de la carte réseau qui est maintenant en full duplex 10bit/S. Après la correction, j'ai cru que ça allait un peu mieux mais en fait ça continue.

Moi je soupçonne un ralentissement réseau / carte réseau mais vos avis seraient les bienvenues.

Voici 2 tops en illustration le premier avec un load average de 5 et quelques minutes plus tard à 1!

Code: Tout sélectionner


top - 16:29:08 up 2 days, 10:06,  1 user,  load average: 5.20, 3.35, 2.22
Tasks:  84 total,   4 running,  80 sleeping,   0 stopped,   0 zombie
Cpu(s): 26.1%us,  7.0%sy,  0.0%ni, 63.9%id,  0.0%wa,  0.3%hi,  2.7%si,  0.0%st
Mem:    481784k total,   465540k used,    16244k free,    39136k buffers
Swap:  1024120k total,      188k used,  1023932k free,   244676k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
1389 mysql     15   0  149m  33m 4776 S 14.6  7.1 251:06.86 mysqld
25136 root      22   0 49260 8604 1076 R  8.0  1.8 122:33.57 pound
10445 apache    23   0 40532  23m  18m R  3.3  5.1   0:56.96 httpd
10456 apache    15   0 40540  23m  18m S  2.0  4.9   0:57.37 httpd
22847 nobody    15   0 11524  10m 9804 S  1.7  2.1  17:01.45 thttpd
2211 apache    15   0 40584  23m  18m S  1.0  5.1   1:49.35 httpd
5375 apache    15   0 40452  16m  11m S  0.7  3.6   0:02.56 httpd
6915 apache    21   0 40796  24m  19m S  0.7  5.2   1:15.40 httpd
10590 apache    17   0 40516  23m  18m S  0.7  5.0   1:00.67 httpd
10591 apache    15   0 40196  23m  18m S  0.7  4.9   1:03.10 httpd
27130 apache    15   0 40748  24m  19m S  0.7  5.2   1:28.47 httpd
2119 apache    17   0 40252  23m  18m S  0.3  5.0   1:53.68 httpd
7600 root      15   0  2160  980  788 R  0.3  0.2   0:00.77 top
13007 apache    15   0 40292  21m  16m S  0.3  4.6   0:11.28 httpd
32278 apache    16   0 40620  16m  11m S  0.3  3.5   0:02.53 httpd
    1 root      15   0  2028  584  508 S  0.0  0.1   0:00.96 init


top - 16:34:50 up 2 days, 10:12,  1 user,  load average: 1.03, 1.97, 1.97
Tasks:  82 total,   2 running,  80 sleeping,   0 stopped,   0 zombie
Cpu(s): 47.8%us, 14.0%sy,  0.0%ni, 35.9%id,  0.0%wa,  0.3%hi,  2.0%si,  0.0%st
Mem:    481784k total,   461668k used,    20116k free,    39188k buffers
Swap:  1024120k total,      188k used,  1023932k free,   245608k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
1389 mysql     15   0  149m  33m 4776 S 39.3  7.1 251:56.93 mysqld
25136 root      15   0 49276 8572 1076 S  4.0  1.8 122:54.97 pound
2119 apache    15   0 40372  23m  18m S  3.3  5.0   1:55.25 httpd
10592 apache    15   0 40260  23m  18m S  3.3  5.0   1:01.40 httpd
18170 apache    15   0 40760  23m  18m S  3.3  5.0   0:44.62 httpd
2211 apache    15   0 40584  23m  18m S  2.0  5.1   1:50.48 httpd
27130 apache    15   0 40748  24m  19m S  1.7  5.2   1:29.76 httpd
6779 apache    25   0 40384  23m  18m S  1.3  4.9   1:15.52 httpd
10428 apache    15   0 40576  23m  18m S  1.0  5.0   0:58.19 httpd
10456 apache    15   0 40540  23m  18m S  1.0  5.0   0:59.37 httpd
5375 apache    15   0 40256  17m  13m S  0.7  3.8   0:04.09 httpd
10583 apache    15   0 40588  24m  19m S  0.7  5.1   1:02.12 httpd
16369 apache    18   0 40384  21m  16m S  0.7  4.6   0:09.35 httpd
22847 nobody    15   0  9848 8668 8128 S  0.7  1.8  17:04.93 thttpd
5476 root      15   0  2160  996  796 R  0.3  0.2   0:00.12 top
6915 apache    15   0 40796  24m  19m S  0.3  5.2   1:17.00 httpd
10591 apache    15   0 40328  23m  18m S  0.3  5.0   1:04.65 httpd
    1 root      15   0  2028  584  508 S  0.0  0.1   0:00.96 init



Bon j'espère que quelqu'un aura lu jusque là Merci

[hebmaster]

load average de 5.20 c'est bcp ...

La normale c'est moins de 1 (0.2 0.5 ...)

C'est quoi ta config ?

[Robinson]

Recontacte le support, ils sont bien mieux placés que nous...

[sietjp]

Ils m'ont dit que c'était peut être du au disque crashé qui est monté en secondaire.

J'ai passé une commande pour les vitesses de lecture écriture du disque et ça donne ça. Est ce que certains d'entre vous pourrait me donner leurs résultats pour que je compare ?

Code: Tout sélectionner

hdparm -tT /dev/hda

/dev/hda:
Timing cached reads:   896 MB in  2.00 seconds = 447.07 MB/sec
Timing buffered disk reads:  120 MB in  3.02 seconds =  39.73 MB/sec


[jcaron]

Quand je charge un page, que j'uploade un fichier vi a ftp ou que je me connecte via la console SSH, il y a souvent un moment d'attente plus long que la normal (quelques secondes) avant que l'action soit traitée. Ca fait un peu comme si on travaillait sur un serveur surchargé, sauf que... il n'est pas surchargé du tout. Et puis pendant quelques minutes les pages se chargent à la vitesse de l lumière (normalement quoi).

Pour moi ça ressemble plus à un problème réseau, non?

J'ai lancé des tops et j'ai eu la surprise de voir que le load average montait de temps en temps à 5 pour edescendre quelques minute plus tard à 1 ! Rien ne permettait d'expliquer ceci, la conso CPU est satble, pas de SWAP, nombre de visiteur stable. Le site est trés boen optimisé au niveau des requêtes mysql, je logue toutes les requêtes au dessus de 1 s et corrige tout ça, de toutes manières je n'avais pas de problème avec ce même site avant le crash du disque dur et la réinstallation...

Le load average est une mesure assez empirique qui rend bien des services, mais est loin d'être quelque chose de toujours très fiable. La mesure de la charge CPU est quelque chose de nettement plus fiable.

J'ai soulevé le problème au support et il s on détecté ue première fois une mamuvaise config de la carte réseau qui est maintenant en full duplex 10bit/S. Après la correction, j'ai cru que ça allait un peu mieux mais en fait ça continue.

Je pense qu'il est possible que le problème soit toujours de ce côté. Tu peux commencer par regarder:
- les taux d'erreurs sur les interfaces (netstat -in sur un BSD, je ne sais plus où c'est sur un Linux)
- ce que donne un ping un peu violent (genre ping -s 1400 -i 0.01 -c 1000) sur l'IP de la passerelle par défaut. Tu ne devrais pas avoir un seul paquet perdu, même une valeur très faible (genre moins de 10 paquets perdus sur 1000) ça suffit à poser des problèmes
- la même chose sur les IPs des différents routeurs sur le chemin vers l'extérieur (que tu peux obtenir en faisant un traceroute de ta machine vers ton IP perso).
- alternativement, tu peux commencer par faire la même chose vers ton IP perso, si tu n'as pas de pertes sur le trajet de bout en bout a priori tu ne devrais pas en avoir sur le chemin non plus (mais avec certains routeurs perso le traceroute peut ne pas passer).

Note que le grand classique en Ethernet ce sont les problèmes de duplex. Et forcer en full duplex n'est pas forcément la solution: un équipement forcé en duplex face à un équipement en auto-négo ça se finit souvent en catastrophe (si l'équipement forcé ne répond pas à la négo, l'équipement en face pensera qu'il à affaire à un équipement passif, donc half-duplex, et se mettra dans ce mode, et ça aboutit à des pertes de paquets assez sévères).

Si tout ça ne montre pas de pb, on peut alors s'orienter vers un problème système. Commencer par examiner les logs (dmesg, /var/log/messages...) pour des choses "graves" genre erreurs de disque, etc. Après, euh, ben on verra

Jacques.

[jcaron]

J'ai lancé des tops et j'ai eu la surprise de voir que le load average montait de temps en temps à 5 pour edescendre quelques minute plus tard à 1 ! Rien ne permettait d'expliquer ceci, la conso CPU est satble, pas de SWAP, nombre de visiteur stable. Le site est trés boen optimisé au niveau des requêtes mysql, je logue toutes les requêtes au dessus de 1 s et corrige tout ça, de toutes manières je n'avais pas de problème avec ce même site avant le crash du disque dur et la réinstallation...

Tiens, un autre truc à regarder (après les problèmes réseau évoqués dans le post précédent): vu le CPU que bouffe ta BDD, il est possible qu'elle bouffe aussi beaucoup d'accès disques, et que ceux-ci soient saturés (pas en place, mais en nombre de requêtes/s possible). Si tu as une grosse base qui ne tient pas en RAM et beaucoup d'accès dans tous les sens c'est généralement le problème le plus classique (une BDD a tendance à être plus souvent "IO-bound" que "CPU-bound" comme on dit). Il doit y avoir des outils pour voir ça sous Linux (sur un BSD ce serait top -m, systat -io, iostat, gstat...).

Jacques.

[fandecine]

Il semble que ton serveur swappe! et ça c'est pas bon!

sinon, un petit "ps aux" complet serait le bienvenue!

[jcaron]

Il semble que ton serveur swappe! et ça c'est pas bon!

Euh non, il ne swappe pas du tout son serveur. Il y a 188K de swap utilisés, autant dire 0...

[sietjp]

Alors est ce que ça swappe ou ça swappe pas ? 188K ça me semble pas lourd mais le support dit que ça swappe un peu aussi.

Concernant les ralentissements, il s'agissait en fait encore d'un problème de la carte réseau qui générait des erreurs. Après la correction, c'était le jour et la nuit, le site carbure maintenant.
Pour info ils ont utilisé la commande ifconfig et dmesg pour diagnostiquer ces problèmes.

Par contre les "load average" sont énormes, plus de 3 en moyenne. Je suppose qu'ils sont dus effectivement à la base de données qui est modérément volumineuse ( 70 megas ).

Le support me conseille de prendre un autre disque dur pour y héberger la base de donnée, qu'en pensez vous ?

[jcaron]

Alors est ce que ça swappe ou ça swappe pas ? 188K ça me semble pas lourd mais le support dit que ça swappe un peu aussi.

188K c'est absolument rien. Ceci dit l'important c'est vraiment de voir combien il y d'activité sur le swap, je ne sais pas comment on voit ça sur un Linux (sur un BSD c'est dans top ou systat -vm ou vmstat).

Concernant les ralentissements, il s'agissait en fait encore d'un problème de la carte réseau qui générait des erreurs. Après la correction, c'était le jour et la nuit, le site carbure maintenant.
Pour info ils ont utilisé la commande ifconfig et dmesg pour diagnostiquer ces problèmes.

Trop fort

Par contre les "load average" sont énormes, plus de 3 en moyenne. Je suppose qu'ils sont dus effectivement à la base de données qui est modérément volumineuse ( 70 megas ).

Comme déjà dit, le load average c'est un truc un peu alambiqué dont la pertinence est difficile à évaluer. Autant des valeurs très faibles ça veut dire que la machine ne fait rien et des valeurs très élevées (>10) ça veut dire qu'elle est plutôt occupée, autant les valeurs intermédiaires (autour de 1) c'est difficile à juger. Pour rappel, le load average c'est une moyenne glissante estimée du nombre de processus en état "runnable" au moment où la mesure est prise. Si c'était une mesure fiable, en dessus de 100% de charge CPU le load average serait égal à la charge CPU, et un load average > 1 impliquerait une charge CPU de 100% (d'un CPU). Or dans la pratique c'est rarement le cas.

Regarde donc plutôt le taux d'utilisation CPU (tu as des graphes là-dessus), le taux d'utilisation des disques (requêtes/s ou %busy), ce sont des mesures nettement plus fiables.

Le support me conseille de prendre un autre disque dur pour y héberger la base de donnée, qu'en pensez vous ?

Sans connaître les détails, impossible à dire...

Jacques.

[sietjp]

Merci bien, quelle est la commande pour le taux d'occupation du disque ?

[jcaron]

Merci bien, quelle est la commande pour le taux d'occupation du disque ?

Sous Linux je n'en sais rien. Sous FreeBSD tu as systat -io, iostat, gstat et top -m qui permettent de voir ce genre de choses. Il doit y avoir des commandes équivalentes sous Linux.

Jacques.