réseau, NFS, MysQL, appli : déterminer ce qui coince

Le
Samuel Cifuentes-Favini
--00151744790efe9edf0482732b15
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Bonjour

je cherche des infos pour pouvoir déterminer ou se trouve un
goulet d'étranglement que j'observe depuis quelques temps.


la conf;

- un "serveur" /squeeze partageant une ressource NFS et une base Mysql
- deux "clients"

un de ces clients est sous sous SID, l'autre sous ubuntu (9.10)


sur chacun de ces clients et sur le serveur, une meme appli tourne
http://www.rivendellaudio.org/index.shtml

lorsque je lance l'appli sur le "serveur" tout est instantanné
lorsque je lance l'appli sur la machine Ubuntu, c'est instantanné
lorsque je lance l'appli sur ma machine SID, elle met environ 25 secondes =
à
s'afficher (c'est une appli graphique, Qt3, (http://www.rivendellaudio.org)

sur les deux clients, les fstab sont identiques

toutes les machines sont sur le même switch, adressage DHCP (sauf le
"serveur")


quelles pistes pourrais-je suivre pour déterminer d'ou vient ce temps de
lancement trés long sur la machine Debian ?

merci par avance

--00151744790efe9edf0482732b15
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Bonjour <div><br></div><div>je cherche des infos pour pouvoir détermi=
ner ou se trouve un goulet d&#39;étranglement que j&#39;observe dep=
uis quelques temps.</div><div><br></div><div><br></div><div>la conf;</div><=
div><br></div>
<div>- un &quot;serveur&quot; /squeeze partageant une ressource NFS et une =
base Mysql</div><div>- deux &quot;clients&quot;</div><div><br></div><div>un=
de ces clients est sous sous SID, l&#39;autre sous ubuntu (9.10)</div>
<div><br></div><div><br></div><div>sur chacun de ces clients et sur le serv=
eur, une meme appli tourne <a href="http://www.rivendellaudio.org/index.s=
html">http://www.rivendellaudio.org/index.shtml</a></div><div><br></div><di=
v>
lorsque je lance l&#39;appli sur le &quot;serveur&quot; tout est instantann=
é</div><div>lorsque je lance l&#39;appli sur la machine Ubuntu, c&#39;e=
st instantanné</div><div>lorsque je lance l&#39;appli sur ma machine SID,=
elle met environ 25 secondes à s&#39;afficher (c&#39;est une appli graph=
ique, Qt3, (<a href="http://www.rivendellaudio.org">http://www.rivendella=
udio.org</a>)</div>
<div><br></div><div>sur les deux clients, les fstab sont identiques</div><d=
iv><br></div><div>toutes les machines sont sur le même switch, adress=
age DHCP (sauf le &quot;serveur&quot;)</div><div><br></div><div><br></div><=
div>
quelles pistes pourrais-je suivre pour déterminer d&#39;ou vient ce t=
emps de lancement trés long sur la machine Debian ?</div><div><br></div><=
div>merci par avance</div>

--00151744790efe9edf0482732b15--

--
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-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/cb5a98cb1003230057w37724ec7p9d41fffb6f790d46@mail.gmail.com
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Grégory Bulot
Le #21423781
Samuel Cifuentes-Favini Mar 2010 08:57:57 +0100


quelles pistes pourrais-je suivre pour déterminer d'ou vient ce temps
de lancement trés long sur la machine Debian ?

merci par avance



problème dns sur la machine lente, je suppose même adressage ip/m asque
réseau :
- hostname -d
- comparaison des cat /etc/resolv.conf
- comparaison des /sbin/route -n
- éventuellement comparaison /sbin/mii-tool


--

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
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Daniel Huhardeaux
Le #21424161
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
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Pascal Hambourg
Le #21424361
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 AAAA 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
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Grégory Bulot
Le #21424591
Pascal Hambourg 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 vienn ent en fait
d'une mauvaise gestion des requêtes AAAA par les serveurs DNS
caches/proxy ou faisant autorité pour le nom demandé. Une captu re 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 gno me ?
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
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Pascal Hambourg
Le #21424741
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
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Samuel Cifuentes-Favini
Le #21424851
--00c09fc2bc7ca8c93b04827592ba
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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 pa s
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 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 écrit :

Pascal Hambourg 2010 10:46:28 +0100


> De toute façon je suis du même avis que Grégory, dans mon expér ience
> les problèmes de latence résolus en désactivant IPv6 viennent en fait
> d'une mauvaise gestion des requêtes AAAA par les serveurs DNS
> caches/proxy ou faisant autorité pour le nom demandé. Une capture d e
> 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
En cas de soucis, contactez EN ANGLAIS
Archive:
http://lists.debian.org/





--00c09fc2bc7ca8c93b04827592ba
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Je precise que la ligne 169.etc. figure sur le résultat de route -n  su r la machine pour laquelle ça **fonctionne** (ubuntu)<div><br></div><div> comme prévu, vi /etc/netwotk/interface (sur la machine ubuntu qui fonctio nne) ne donne que</div>

<div><br></div><div>***********</div><div>auto lo</div><div>iface lo inet l oopback</div><div>*************</div><div>c&#39;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)</div>

<div><br></div><div><br></div><div>sur ma Sid, le /etc/network/interfaces e st normal</div><div>*******************************</div><div><div># This f ile describes the network interfaces available on your system</div><div>

# and how to activate them. For more information, see interfaces(5).</div>< div><br></div><div># The loopback network interface</div><div>auto lo</div> <div>iface lo inet loopback</div><div><br></div><div># The primary network interface</div>

<div>allow-hotplug eth0</div><div>iface eth0 inet dhcp</div></div><div>**** ********************************</div><div><br></div><div>@Pascal : </div ><div><br></div><div>ma tentative de sniff wireshark me donne bien des lign es mentionnant mDNS  !</div>



2010 10:46:28 +0100<br>
<div><br>
<br>
&gt; De toute façon je suis du même avis que Grégory, dans mon expé rience<br>
&gt; les problèmes de latence résolus en désactivant IPv6 viennent en fait<br>
&gt; d&#39;une mauvaise gestion des requêtes AAAA par les serveurs DNS<br >
&gt; caches/proxy ou faisant autorité pour le nom demandé. Une capture de<br>
&gt; trafic pourrait en apprendre plus.<br>
<br>
</div>L&#39;auteur du post m&#39;a répondu en privé par erreur,<br>
<br>
l&#39;ensemble semble identique avec les autres machines<br>
<br>
sur le route -n ceci figure en plus :<br>
<br>
</div>Ce qui me parait étonnant : cela veut dire qu&#39;aucun serveur dhc p n&#39;a été<br>
trouvé pour l&#39;interface eth0 qui est clientte DHCP, il me semble.<br>
<br>
ifconfig donne quoi ?, y aurait pas plusieurs fois eth0 ?<br>
Y aurait pas eu des tentatives ip fixe / dhcp ?<br>
il y a quoi dans ton  cat /etc/network/interfaces ?<br>
<br>
As-tu la possibilité de désactiver/stopper network manager de gnome ?<b r>
 si oui après faire un ifconfig eth0 down ; ifconfig eth0 up<br>
 fermer ton navigateur, le relancer et retenter<br>
<br>
Ce ne sont que des idées posées en vrac<br>
<br>
<br>
--<br>
<br>
Cordialement<br>
Grégory BULOT<br>
<div><br>
--<br>
Lisez la FAQ de la liste avant de poser une question :<br>
<br>
Pour vous DESABONNER, envoyez un message avec comme objet &quot;unsubscribe &quot;<br>
vers En cas de soucis, contactez EN ANGLAIS <br>
</blockquote></div><br></div>

--00c09fc2bc7ca8c93b04827592ba--

--
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
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Pascal Hambourg
Le #21425071
(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 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
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Samuel Cifuentes-Favini
Le #21426061
Le 23 mars 2010 12:40, Pascal Hambourg
(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 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
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Pascal Hambourg
Le #21426231
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=2.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
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Samuel Cifuentes-Favini
Le #21429671
--001485ea7a6897947a048286ba7d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Le 23 mars 2010 16:45, Pascal Hambourg :

Samuel Cifuentes-Favini a écrit :
>
> Voici le résultat de la capture sur la machine ubuntu pour laquell e 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=2.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 pa r 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'accuei l
(greeting) par le serveur. On ne voit pas les éventuelles répon ses à 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 My SQL
apparemment plus anciennes, et un broadcast NTP qui passait par là m ais
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 My SQL
192.168.80.150 à destination de 192.168.65.100 (qui doit correspondr e à
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 swit ch.




ç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 serv eur 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
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/





--001485ea7a6897947a048286ba7d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


<div>Samuel Cifuentes-Favini a écrit :<br>
&gt;<br>
</div><div>&gt; Voici le résultat de la capture sur la machine ubuntu pour laquelle le<br>
&gt; lancement de l&#39;appli est quasi instantanné<br>
&gt;<br>
&gt; désolé, c&#39;est un peu long....<br>
<br>


<div><br>
&gt; filtrage : ip.addr=2.168.80.150<br>
<br>
[...]<br>
<div>&gt; voici maintenant meme resultat sur la SID<br>
&gt; le lancement de l&#39;appli est indiqué à la trame 65017.027 ...<br>
&gt; meme &quot;serveur&quot; (192.168.80.150)<br>
&gt; client en 192.168.84.102<br>
&gt; meme filtrage, apparition de l&#39;appli à la trame commença nt par 206,<br>
<br>
</div>La différence avec la trace prédédente, ce sont ces re quêtes inverses<br>
DNS et mDNS répétées émises par le serveur 192.168.80.1 50 entre<br>
l&#39;établissement de la connexion MySQL et l&#39;envoi du message d& #39;accueil<br>
(greeting) par le serveur. On ne voit pas les éventuelles réponse s à ces<br>
requêtes DNS et mDNS, et on peut penser que leur absence est<br>
probablement la cause du délai.<br>
<br>
(Il y a aussi des paquets qui appartiennent à d&#39;autres connexions MySQL<br>
apparemment plus anciennes, et un broadcast NTP qui passait par là mai s<br>
n&#39;a rien à voir a priori).<br>
<br>
Un détail me chagrine : les captures ont été faites sur le c lient à<br>
chaque fois, et non sur le serveur ?
Mais dans ce cas, je ne m&#39;explique<br>
pas comment on voit les requêtes DNS envoyées par le serveur MySQ L<br>
192.168.80.150 à destination de 192.168.65.100 (qui doit correspondre à<br>
un serveur DNS),
le client n&#39;est pas censé les voir sauf si le client et<br>
le serveur sont connectés en coaxial ou par un hub au lieu d&#39;un sw itch.

<br>
Il serait intéressant de refaire les mêmes captures sur le serveu r cette<br>
fois, et sans filtrage, pour voir les requêtes et les réponses DN S et<br>
mDNS. Si le serveur envoie des requêtes inverses pour l&#39;adresse IP d&#39;un<br>
client mais pas pour l&#39;autre, c&#39;est peut-être qu&#39;une adres se figure dans<br>
le fichier /etc/hosts du serveur mais pas l&#39;autre. Il devrait suffire d e<br>
l&#39;ajouter.<br>
<div>
--<br>
Lisez la FAQ de la liste avant de poser une question :<br>
<br>
Pour vous DESABONNER, envoyez un message avec comme objet &quot;unsubscribe &quot;<br>
vers En cas de soucis, contactez EN ANGLAIS <br>
</blockquote></div><br>

--001485ea7a6897947a048286ba7d--

--
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
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Publicité
Poster une réponse
Anonyme