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
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
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
Bonjour
[...]
quelles pistes pourrais-je suivre pour déterminer d'ou vient ce temps
de lancement trés long sur la machine Debian ?
Bonjour
[...]
quelles pistes pourrais-je suivre pour déterminer d'ou vient ce temps
de lancement trés long sur la machine Debian ?
Bonjour
[...]
quelles pistes pourrais-je suivre pour déterminer d'ou vient ce temps
de lancement trés long sur la machine Debian ?
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 ;-)
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 ;-)
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 ;-)
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.
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.
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.
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.
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.
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.
Pascal Hambourg à é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é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/
Pascal Hambourg <pascal.mail@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é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 debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive:
http://lists.debian.org/20100323111407.1c0c8c0d@morpheus.bulot-fr.com
Pascal Hambourg à é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é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/
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)
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)
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)
(ouille, merci d'éviter le HTML à l'avenir !)
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 ?
(ouille, merci d'éviter le HTML à l'avenir !)
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 ?
(ouille, merci d'éviter le HTML à l'avenir !)
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 ?
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=2.168.80.150
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,
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=2.168.80.150
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,
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=2.168.80.150
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,
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.
> 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 ?
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),
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.
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/
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.
> 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 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 ?
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),
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.
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 debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/4BA8E227.6060801@plouf.fr.eu.org
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.
> 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 ?
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),
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.
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/