Re: réseau, NFS, MysQL, appli : déterminer ce qui coince
Le 23 mars 2010 16:45, Pascal Hambourg pascal.m...@plouf.fr.eu.org a écrit : Samuel Cifuentes-Favini a écrit : Voici le résultat de la capture sur la machine ubuntu pour laquelle le lancement de l'appli est quasi instantanné désolé, c'est un peu long Non, deux fois moins que le message en HTML précédent. ok, ok. ^^ filtrage : ip.addr==192.168.80.150 J'avais demandé pas de filtrage. [...] voici maintenant meme resultat sur la SID le lancement de l'appli est indiqué à la trame 65017.027... meme serveur (192.168.80.150) client en 192.168.84.102 meme filtrage, apparition de l'appli à la trame commençant par 206, La différence avec la trace prédédente, ce sont ces requêtes inverses DNS et mDNS répétées émises par le serveur 192.168.80.150 entre l'établissement de la connexion MySQL et l'envoi du message d'accueil (greeting) par le serveur. On ne voit pas les éventuelles réponses à ces requêtes DNS et mDNS, et on peut penser que leur absence est probablement la cause du délai. (Il y a aussi des paquets qui appartiennent à d'autres connexions MySQL apparemment plus anciennes, et un broadcast NTP qui passait par là mais n'a rien à voir a priori). Un détail me chagrine : les captures ont été faites sur le client à chaque fois, et non sur le serveur ? exact, sur chacun des clients en effet Mais dans ce cas, je ne m'explique pas comment on voit les requêtes DNS envoyées par le serveur MySQL 192.168.80.150 à destination de 192.168.65.100 (qui doit correspondre à un serveur DNS), en effet, moi non plus. Le fait que le client (je dis bien le client et non le serveur) abrite un proxy squid pourrait-il expliquer ça ? oui, 65.100 est un DNS le client n'est pas censé les voir sauf si le client et le serveur sont connectés en coaxial ou par un hub au lieu d'un switch. ça, je ne me l'explique pas en effet . c'est bien un switch Il serait intéressant de refaire les mêmes captures sur le serveur cette fois, et sans filtrage, pour voir les requêtes et les réponses DNS et mDNS. Si le serveur envoie des requêtes inverses pour l'adresse IP d'un client mais pas pour l'autre, c'est peut-être qu'une adresse figure dans le fichier /etc/hosts du serveur mais pas l'autre. Il devrait suffire de l'ajouter. bonne idée, je vais regarder le /etc/hosts -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4ba8e227.6060...@plouf.fr.eu.org
Resolu: réseau, NFS, MysQL, appli : déterminer ce qui coince
Je viens de rajouter l'@ de la machine SID dans le /etc/host du serveur le résultat est immédiat, l'appli se lance instantanément ! malheureusement, j'ai besoin de travailler sur l'appli (j'ai pris du retard) et je ne peux pas actuellement creuser plus profondément la question de savoir pourquoi, de deux machines déclarées en DHCP, non identifiées dans aucun fichier host, l'une présentait ce genre de probleme je vais quand meme essayer de me procurer un autre switch pour voir pourquoi autant de choses passaient qui n'étaient nullement destinées aux machines en question. si vous avez besoin de détails sur la conf, pour parfaire la compréhension du souci ou pour pouvoir servir aux lecteurs futurs de ce fil, n'hésitez pas à demander. Un grand merci à chacun pour votre aide ! Samuel -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/cb5a98cb1003240045r5945da67ge6cb499e15157...@mail.gmail.com
Re: réseau, NFS, MysQL, appli : déterminer ce qui coince
Je viens de rajouter l'@ de la machine SID dans le /etc/host du serveur le résultat est immédiat, l'appli se lance instantanément ! malheureusement, j'ai besoin de travailler sur l'appli (j'ai pris du retard) et je ne peux pas actuellement creuser plus profondément la question de savoir pourquoi, de deux machines déclarées en DHCP, non identifiées dans aucun fichier host, l'une présentait ce genre de probleme je vais quand meme essayer de me procurer un autre switch pour voir pourquoi autant de choses passaient qui n'étaient nullement destinées aux machines en question. si vous avez besoin de détails sur la conf, pour parfaire la compréhension du souci ou pour pouvoir servir aux lecteurs futurs de ce fil, n'hésitez pas à demander. Un grand merci à chacun pour votre aide ! Samuel PS: il s'agit de ma deuxième tentative d'envoi de ce mail de remerciement à la liste. Je n'ai pas reçu le premier. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/cb5a98cb1003240405l3b0d66a6k6477db4fdd968...@mail.gmail.com
Re: réseau, NFS, MysQL, appli : déterminer ce qui coince
Samuel Cifuentes-Favini a écrit : Bonjour Bonjour [...] quelles pistes pourrais-je suivre pour déterminer d'ou vient ce temps de lancement trés long sur la machine Debian ? Retire la gestion ipv6, si bien sur tu n'es pas passe en ipv6 ;-) -- Daniel -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4ba88718.6030...@tootai.net
Re: réseau, NFS, MysQL, appli : déterminer ce qui coince
Salut, Daniel Huhardeaux a écrit : Samuel Cifuentes-Favini a écrit : [...] quelles pistes pourrais-je suivre pour déterminer d'ou vient ce temps de lancement trés long sur la machine Debian ? Retire la gestion ipv6, si bien sur tu n'es pas passe en ipv6 ;-) Si je ne m'abuse la gestion d'IPv6 dans le noyau de sid est maintenant en dur et non plus en module, donc ça ne va pas être du gâteau. De toute façon je suis du même avis que Grégory, dans mon expérience les problèmes de latence résolus en désactivant IPv6 viennent en fait d'une mauvaise gestion des requêtes par les serveurs DNS caches/proxy ou faisant autorité pour le nom demandé. Une capture de trafic pourrait en apprendre plus. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4ba88df4.4040...@plouf.fr.eu.org
Re: réseau, NFS, MysQL, appli : déterminer ce qui coince
Grégory Bulot a écrit : sur le route -n ceci figure en plus : 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0 Ce qui me parait étonnant : cela veut dire qu'aucun serveur dhcp n'a été trouvé pour l'interface eth0 qui est clientte DHCP, il me semble. Pas forcément. La plage d'adresses link local peut être utilisée par les machins du style zeroconf/avahi indépendamment de la configuration DHCP ou statique. En y pensant, la latence vient peut-être d'une tentative de résolution de nom avec mDNS (multicast DNS, une des fonctionnalités de zeroconf/avahi). -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4ba8997d.7030...@plouf.fr.eu.org
Re: réseau, NFS, MysQL, appli : déterminer ce qui coince
Je precise que la ligne 169.etc. figure sur le résultat de route -n sur la machine pour laquelle ça **fonctionne** (ubuntu) comme prévu, vi /etc/netwotk/interface (sur la machine ubuntu qui fonctionne) ne donne que *** auto lo iface lo inet loopback * c'est donc le network-manager de gnome qui est utilisé (je ne connais pas du tout sur cette machine-ci, les temps de réponse sont normaux) sur ma Sid, le /etc/network/interfaces est normal *** # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface allow-hotplug eth0 iface eth0 inet dhcp @Pascal : ma tentative de sniff wireshark me donne bien des lignes mentionnant mDNS ! elles sont en rouge (erreur ?) les voici : 332 69.695505 192.168.80.150 224.0.0.251 MDNS Standard query PTR 104.85.168.192.in-addr.arpa, QM question 337 70.711944 192.168.80.150 224.0.0.251 MDNS Standard query PTR 104.85.168.192.in-addr.arpa, QM question 342 72.730062 192.168.80.150 224.0.0.251 MDNS Standard query PTR 104.85.168.192.in-addr.arpa, QM question il y a d'autres choses bizarres (mais que je ne sais pas interpreter) 354 76.936145 192.168.80.150 192.168.85.104 MySQL [TCP Out-Of-Order] Server Greeting proto=10 version=5.0.51a-24+lenny3 oui, le serveur mySQL+ NFS est sous lenny (il a pour adresse 192.168.80.150) Le 23 mars 2010 11:14, Grégory Bulot debian.list200...@batman.dyndns.org a écrit : Pascal Hambourg pascal.m...@plouf.fr.eu.org à écrit le Tue, 23 Mar 2010 10:46:28 +0100 De toute façon je suis du même avis que Grégory, dans mon expérience les problèmes de latence résolus en désactivant IPv6 viennent en fait d'une mauvaise gestion des requêtes par les serveurs DNS caches/proxy ou faisant autorité pour le nom demandé. Une capture de trafic pourrait en apprendre plus. L'auteur du post m'a répondu en privé par erreur, l'ensemble semble identique avec les autres machines sur le route -n ceci figure en plus : 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0 Ce qui me parait étonnant : cela veut dire qu'aucun serveur dhcp n'a été trouvé pour l'interface eth0 qui est clientte DHCP, il me semble. ifconfig donne quoi ?, y aurait pas plusieurs fois eth0 ? Y aurait pas eu des tentatives ip fixe / dhcp ? il y a quoi dans ton cat /etc/network/interfaces ? As-tu la possibilité de désactiver/stopper network manager de gnome ? si oui après faire un ifconfig eth0 down ; ifconfig eth0 up fermer ton navigateur, le relancer et retenter Ce ne sont que des idées posées en vrac -- Cordialement Grégory BULOT -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20100323111407.1c0c8...@morpheus.bulot-fr.com
Re: réseau, NFS, MysQL, appli : déterminer ce qui coince
(ouille, merci d'éviter le HTML à l'avenir !) Samuel Cifuentes-Favini a écrit : ma tentative de sniff wireshark me donne bien des lignes mentionnant mDNS ! elles sont en rouge (erreur ?) les voici : 332 69.695505 192.168.80.150 224.0.0.251 MDNS Standard query PTR 104.85.168.192.in-addr.arpa, QM question 337 70.711944 192.168.80.150 224.0.0.251 MDNS Standard query PTR 104.85.168.192.in-addr.arpa, QM question 342 72.730062 192.168.80.150 224.0.0.251 MDNS Standard query PTR 104.85.168.192.in-addr.arpa, QM question Ce sont des requêtes émises par 192.168.80.150 (le serveur si j'ai bien compris) de résolution inverse de l'adresse 192.168.85.104 (c'est qui ?) il y a d'autres choses bizarres (mais que je ne sais pas interpreter) 354 76.936145 192.168.80.150 192.168.85.104 MySQL [TCP Out-Of-Order] Server Greeting proto=10 version=5.0.51a-24+lenny3 Qu'est-ce que tu trouves bizarre ? La datation de ces paquets se situe entre 69 et 77 secondes, mais quand se situe le lancement de l'application sur le client sid par rapport à cette capture ? Tu parlais d'un délai de 25 secondes ? Je répète qu'il faudrait examiner tout le trafic entre le lancement de l'application et le début de l'affichage, pas juste quelques fragments isolés. oui, le serveur mySQL+ NFS est sous lenny (il a pour adresse 192.168.80.150) lenny ou squeeze ? Dans le premier message tu écrivais que le serveur était sous squeeze. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4ba8a89c.8030...@plouf.fr.eu.org
Re: réseau, NFS, MysQL, appli : déterminer ce qui coince
merci de votre patience ! Voici le résultat de la capture sur la machine ubuntu pour laquelle le lancement de l'appli est quasi instantanné désolé, c'est un peu long filtrage : ip.addr==192.168.80.150 serveur lenny/squeeze (comme expliqué ici http://forum.debian-fr.org/viewtopic.php?f=8t=5659) adresse 192.168.80.150 client ubuntu 9.10 adresse 192.168.84.56 le masque est en 255.255.248.0 la première trame (41.12.etc.. s'est affichée dés que j'ai cliqué sur le bouton de l'appli la dernière trame lorsque j'ai vu apparaitre l'appli (à trés peu de choses prés) *** No. Time Source Destination Protocol Info 41 12.998613 192.168.84.56 192.168.80.150 TCP 58110 mysql [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=3892447 TSER=0 WS=6 42 12.998806 192.168.80.150 192.168.84.56 TCP mysql 58110 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=477104811 TSER=3892447 WS=6 43 12.998839 192.168.84.56 192.168.80.150 TCP 58110 mysql [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSV=3892447 TSER=477104811 44 12.999340 192.168.80.150 192.168.84.56 MySQL Server Greeting proto=10 version=5.0.51a-24+lenny3 45 12.999384 192.168.84.56 192.168.80.150 TCP 58110 mysql [ACK] Seq=1 Ack=68 Win=5888 Len=0 TSV=3892448 TSER=477104811 46 13.002513 192.168.84.56 192.168.80.150 MySQL Login Request user=rduser db=Rivendell 47 13.006697 192.168.80.150 192.168.84.56 TCP mysql 58110 [ACK] Seq=68 Ack=75 Win=5824 Len=0 TSV=477104813 TSER=3892448 48 13.006794 192.168.80.150 192.168.84.56 MySQL Response OK 49 13.006955 192.168.84.56 192.168.80.150 MySQL Request Use Database 50 13.009885 192.168.80.150 192.168.84.56 MySQL Response OK 51 13.011174 192.168.84.56 192.168.80.150 MySQL Request Query 52 13.012528 192.168.80.150 192.168.84.56 MySQL Response 53 13.012980 192.168.84.56 192.168.80.150 MySQL Request Query 54 13.013149 192.168.80.150 192.168.84.56 MySQL Response 55 13.050945 192.168.84.56 192.168.80.150 TCP 58110 mysql [ACK] Seq=143 Ack=258 Win=5888 Len=0 TSV=3892461 TSER=477104814 63 13.392248 192.168.84.56 192.168.80.150 MySQL Request Query 64 13.392849 192.168.80.150 192.168.84.56 MySQL Response 65 13.393122 192.168.84.56 192.168.80.150 TCP 39416 mysql [ACK] Seq=65 Ack=102 Win=175 Len=0 TSV=3892546 TSER=477104909 *** voici maintenant meme resultat sur la SID le lancement de l'appli est indiqué à la trame 65017.027... meme serveur (192.168.80.150) client en 192.168.84.102 meme filtrage, apparition de l'appli à la trame commençant par 206, No. Time Source Destination Protocol Info 11 3.185995 192.168.84.102 192.168.80.150 MySQL Request Query 12 3.186281 192.168.80.150 192.168.84.102 MySQL Response 13 3.186313 192.168.84.102 192.168.80.150 TCP 56217 mysql [ACK] Seq=28 Ack=85 Win=209 Len=0 TSV=2168437 TSER=476841220 65 17.027146 192.168.84.102 192.168.80.150 TCP 42405 mysql [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=2171897 TSER=0 WS=6 66 17.027289 192.168.80.150 192.168.84.102 TCP mysql 42405 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=476844680 TSER=2171897 WS=6 67 17.027309 192.168.84.102 192.168.80.150 TCP 42405 mysql [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSV=2171897 TSER=476844680 98 22.030789 192.168.80.150 192.168.65.100 DNS Standard query PTR 102.84.168.192.in-addr.arpa 142 32.927377 192.168.84.102 192.168.80.150 MySQL Request Query 143 32.927613 192.168.80.150 192.168.84.102 MySQL Response 144 32.927638 192.168.84.102 192.168.80.150 TCP 56322 mysql [ACK] Seq=28 Ack=85 Win=364 Len=0 TSV=2175872 TSER=476848655 145 33.038158 192.168.80.150 192.168.65.100 DNS Standard query PTR 102.84.168.192.in-addr.arpa 173 39.145998 192.168.80.150 224.0.0.251 MDNS Standard query PTR 102.84.168.192.in-addr.arpa, QM question 176 40.150012 192.168.80.150 224.0.0.251 MDNS Standard query PTR 102.84.168.192.in-addr.arpa, QM question 182 42.158187 192.168.80.150 224.0.0.251 MDNS Standard query PTR 102.84.168.192.in-addr.arpa, QM question 186 43.853017 192.168.80.150 192.168.87.255 NTP NTP broadcast 187 44.050100 192.168.80.150 192.168.84.102 MySQL Server Greeting proto=10 version=5.0.51a-24+lenny3 188 44.050141 192.168.84.102
Re: réseau, NFS, MysQL, appli : déterminer ce qui coince
Le 23 mars 2010 12:40, Pascal Hambourg pascal.m...@plouf.fr.eu.org a écrit : (ouille, merci d'éviter le HTML à l'avenir !) ouch ! scuse... mauvaise conf de mon gmail il y a d'autres choses bizarres (mais que je ne sais pas interpreter) 354 76.936145 192.168.80.150 192.168.85.104 MySQL [TCP Out-Of-Order] Server Greeting proto=10 version=5.0.51a-24+lenny3 Qu'est-ce que tu trouves bizarre ? le TCP-Out-of-Order mais je me suis renseigné depuis, effectivement, cela fait partie du fonctionnement normal du protocole A+ -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/cb5a98cb1003230805u100140d3o9df64705fe775...@mail.gmail.com
Re: réseau, NFS, MysQL, appli : déterminer ce qui coince
Samuel Cifuentes-Favini a écrit : Voici le résultat de la capture sur la machine ubuntu pour laquelle le lancement de l'appli est quasi instantanné désolé, c'est un peu long Non, deux fois moins que le message en HTML précédent. filtrage : ip.addr==192.168.80.150 J'avais demandé pas de filtrage. [...] voici maintenant meme resultat sur la SID le lancement de l'appli est indiqué à la trame 65017.027... meme serveur (192.168.80.150) client en 192.168.84.102 meme filtrage, apparition de l'appli à la trame commençant par 206, La différence avec la trace prédédente, ce sont ces requêtes inverses DNS et mDNS répétées émises par le serveur 192.168.80.150 entre l'établissement de la connexion MySQL et l'envoi du message d'accueil (greeting) par le serveur. On ne voit pas les éventuelles réponses à ces requêtes DNS et mDNS, et on peut penser que leur absence est probablement la cause du délai. (Il y a aussi des paquets qui appartiennent à d'autres connexions MySQL apparemment plus anciennes, et un broadcast NTP qui passait par là mais n'a rien à voir a priori). Un détail me chagrine : les captures ont été faites sur le client à chaque fois, et non sur le serveur ? Mais dans ce cas, je ne m'explique pas comment on voit les requêtes DNS envoyées par le serveur MySQL 192.168.80.150 à destination de 192.168.65.100 (qui doit correspondre à un serveur DNS), le client n'est pas censé les voir sauf si le client et le serveur sont connectés en coaxial ou par un hub au lieu d'un switch. Il serait intéressant de refaire les mêmes captures sur le serveur cette fois, et sans filtrage, pour voir les requêtes et les réponses DNS et mDNS. Si le serveur envoie des requêtes inverses pour l'adresse IP d'un client mais pas pour l'autre, c'est peut-être qu'une adresse figure dans le fichier /etc/hosts du serveur mais pas l'autre. Il devrait suffire de l'ajouter. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4ba8e227.6060...@plouf.fr.eu.org
