DNS et GSSAPI sont souvent impliqués lorsque la connexion met « longtemps » à s'établir mais si les « freezes » se produisent pendant la session, il semble peu probable que ça soit lié.
Je suppose que le client reste réactif lorsque le problème se produit ? Ce qui signifie que le problème est soit au niveau réseau soit au niveau serveur. Si le load average reste effectivement proche de 0 juste après le problème, il semble plus probable que le réseau en soit la source.
Les idées qui me viennent à l'esprit pour tenter de diagnostiquer le problème seraient :
* pinguer le serveur en continu et voir s'il y a une augmentation de la latence ou des pertes de paquets lorsque le problème se produit ;
* tcpdumper des deux côtés jusqu'à ce que le problème se produise et voir lequel des deux arrète d'emettre lorsqu'il devrait (ou bien s'ils émettent tous les deux et qu'il y a des paquets qui se perdent) ;
* laisser tourner un truc genre "while true ; do date ; sleep 1 ; done > date.log" sur le serveur et voir si la séquence est ralentie lorsque le problème se produit ;
* ajouter des -v à ta ligne de commande ssh, relancer sshd en mode debug et voir si tu as des indices qui apparaissent lorsque le problème se produit ;
* stracer sshd et voir dans quel(s) appel(s) système(s) ça coince ;
* si tu peux obtenir un accès physique de manière pratique lorsque le problème se produit, essai de voir si la console locale est elle aussi « freezée » auquel cas tu pourrais commencer par un sysrq-t.
À partir de là, si tu n'as toujours pas trouvé tu devrais au moins savoir s'il s'agit d'un problème réseau (auquel cas tu peux éliminer les éléments intermédiaires jusqu'à trouver le fautif) ou local (auquel cas il va être temps d'apprendre à comprendre ce que strace et sysrq-t racontent).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# -vvv, ping, tcpdump, strace, sysrq-t
Posté par Krunch (courriel, site web personnel) . En réponse au message latences invite de commande en connexion ssh. Évalué à 3. Dernière modification le 15 octobre 2012 à 20:38.
DNS et GSSAPI sont souvent impliqués lorsque la connexion met « longtemps » à s'établir mais si les « freezes » se produisent pendant la session, il semble peu probable que ça soit lié.
Je suppose que le client reste réactif lorsque le problème se produit ? Ce qui signifie que le problème est soit au niveau réseau soit au niveau serveur. Si le load average reste effectivement proche de 0 juste après le problème, il semble plus probable que le réseau en soit la source.
Les idées qui me viennent à l'esprit pour tenter de diagnostiquer le problème seraient :
* pinguer le serveur en continu et voir s'il y a une augmentation de la latence ou des pertes de paquets lorsque le problème se produit ;
* tcpdumper des deux côtés jusqu'à ce que le problème se produise et voir lequel des deux arrète d'emettre lorsqu'il devrait (ou bien s'ils émettent tous les deux et qu'il y a des paquets qui se perdent) ;
* laisser tourner un truc genre "while true ; do date ; sleep 1 ; done > date.log" sur le serveur et voir si la séquence est ralentie lorsque le problème se produit ;
* ajouter des -v à ta ligne de commande ssh, relancer sshd en mode debug et voir si tu as des indices qui apparaissent lorsque le problème se produit ;
* stracer sshd et voir dans quel(s) appel(s) système(s) ça coince ;
* si tu peux obtenir un accès physique de manière pratique lorsque le problème se produit, essai de voir si la console locale est elle aussi « freezée » auquel cas tu pourrais commencer par un sysrq-t.
À partir de là, si tu n'as toujours pas trouvé tu devrais au moins savoir s'il s'agit d'un problème réseau (auquel cas tu peux éliminer les éléments intermédiaires jusqu'à trouver le fautif) ou local (auquel cas il va être temps d'apprendre à comprendre ce que strace et sysrq-t racontent).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.