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

[Pascal Hambourg <pascal.mail@plouf.fr.eu.org>]

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.