|
Recherche |
Le client nous remonte l'information que sa machine reste bridée à 512Kbs alors qu'il avait acheté 512Kbs en plus. La machine semble être lente et ça n'avance pas beaucoup. La première chose consiste à bien constater que la machine n'est pas réellement bridée en bande passante. Pour cela, on lance le téléchargement d'un gros fichier à partir d'une autre machine sur un autre réseau. Le téléchargement à partir du serveur de backup nous confirme que la machine pulse bien. C'est normal puisque la bande passante n'est pas limitée vers backup. Nous faisons un téléchargement à partir d'une autre machine et là nous avons bien une limitation de bande passante : 3050K .......... .......... .......... .......... .......... 4% @ 43.86 KB/s 3100K .......... .......... .......... .......... .......... 4% @ 43.86 KB/s 3150K .......... .......... .......... .......... .......... 4% @ 38.20 KB/s 3200K .......... .......... .......... .......... .......... 4% @ 41.29 KB/s 3250K .......... .......... .......... .......... .......... 5% @ 37.31 KB/s 3300K .......... .......... .......... .......... .......... 5% @ 39.06 KB/s 3350K .......... .......... .......... .......... .......... 5% @ 43.14 KB/s 3400K .......... .......... .......... .......... .......... 5% @ 46.30 KB/s 3450K .......... .......... .......... .......... .......... 5% @ 43.82 KB/s 3500K .......... .......... .......... .......... .......... 5% @ 37.88 KB/s 3550K .......... .......... .......... .......... .......... 5% @ 41.67 KB/s 3600K .......... .......... .......... .......... .......... 5% @ 41.63 KB/s 3650K .......... .......... .......... .......... .......... 5% @ 39.09 KB/s 3700K .......... .......... .......... .......... .......... 5% @ 38.46 KB/s 3750K .......... .......... .......... .......... .......... 5% @ 39.03 KB/s C'est bien limité et très serré... hmmm... Pendant ce téléchargement, on a vu, lors de la connexion sur le serveur http à distance, que c'est le delai de connexion : on va essayer de voir si c'est aussi le cas en local : # time telnet localhost 80 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. HEAD / HTTP/1.0 HTTP/1.1 200 OK Date: Sun, 02 Nov 2003 17:53:36 GMT Server: Apache/1.3.28 (Unix) mod_gzip/1.3.19.1a PHP/4.3.3 mod_ssl/2.8.15 OpenSSL/0.9.6i Content-Location: index.html.en Vary: negotiate,accept-language,accept-charset TCN: choice Last-Modified: Wed, 13 Nov 2002 23:46:09 GMT ETag: "f5a-a71-3dd2e441;3f22f7c3" Accept-Ranges: bytes Content-Length: 2673 Connection: close Content-Type: text/html Content-Language: en Expires: Sun, 02 Nov 2003 17:53:36 GMT Connection closed by foreign host. real 0m13.382s user 0m0.000s sys 0m0.000s 13 secondes pour repondre à un HEAD, ça fait beaucoup. Problème dns ? #tail -f /var/log/messages Nov 2 18:50:41 ns3524 named[23903]: client 213.186.36.151#2038: error sending response: host unreachable Nov 2 18:50:45 ns3524 named[23903]: client 213.186.36.151#2044: error sending response: host unreachable Nov 2 18:50:45 ns3524 named[23903]: client 213.186.36.151#2045: error sending response: host unreachable Nov 2 18:50:51 ns3524 named[23903]: client 213.186.36.151#2055: error sending response: host unreachable Nov 2 18:51:10 ns3524 named[23903]: client 200.193.136.60#32772: error sending response: host unreachable Nov 2 18:51:25 ns3524 named[23903]: client 213.186.36.151#2112: error sending response: host unreachable Ce n'est pas formidable. On va essayer de redémarrer named pour voir si c'est mieux : #/etc/rc.d/init.d/named restart Arrêt de named : [ OK ] Démarrage de named : [OK ] un coup d'oeil dans /var/log/messages ... rien d'anormal. un coup d'oeil dans /var/named ... rien d'anormal. un coup d'oeil dans /etc/named.conf ... rien d'anormal. Hmmm... on lance dmesg et on trouve : bug: kernel timer added twice at c01a14b7. bug: kernel timer added twice at c01a14b7. bug: kernel timer added twice at c01a14b7. bug: kernel timer added twice at c01a14b7. bug: kernel timer added twice at c01a14b7. C'est quel kernel ? # uname -a Linux xxxx.ovh.net 2.4.20 #1 dim déc 15 15:07:28 CET 2002 i686 unknown 2.4.20 ... on va essayer de mettre 2.4.21 pour voir si ça ne peut pas régler le problème. Pendant la mise à jour du lilo on a vu dans /etc/lilo.conf image=/boot/bzImage-2.4.20-ns3xxx-36 C'est un noyau avec une limitation de bande passante dans le noyau (sauf vers backup). Après la mise à jour du kernel : # uname -a Linux xxxxx.ovh.net 2.4.21 #1 mar jun 17 15:44:13 CEST 2003 i686 unknown # telnet localhost 80 Trying 127.0.0.1... Connected to localhost. Escape character is '^'. HEAD / HTTP/1.0 HTTP/1.1 200 OK Date: Sun, 02 Nov 2003 18:13:12 GMT Server: Apache/1.3.28 (Unix) mod_gzip/1.3.19.1a PHP/4.3.3 mod_ssl/2.8.15 OpenSSL/0.9.6i Content-Location: index.html.en Vary: negotiate,accept-language,accept-charset TCN: choice Last-Modified: Wed, 13 Nov 2002 23:46:09 GMT ETag: "f5a-a71-3dd2e441;3f22f7c3" Accept-Ranges: bytes Content-Length: 2673 Connection: close Content-Type: text/html Content-Language: en Expires: Sun, 02 Nov 2003 18:13:12 GMT Connection closed by foreign host. Résultat : ça pulse. Conclusion La limitation de bande passante n'a pas été effectuée sur les switchs mais sur la machine directement. Ce qui fait que le client pouvait acheter de la bande passante en plus et ça ne servait à rien. Il va donc être remboursé pour la bande passante payée. |
