Ceci est probablement une continuation de ma question précédente (sans réponse) car la cause sous-jacente est probablement la même.
J'ai un serveur Linux avec nginx et sshd en cours d'exécution dessus. Il est sur un lien partagé à 100 Mbit/s sans limite de données. Pendant les "heures de pointe" (essentiellement, pendant la journée aux États-Unis), les performances de sftp deviennent très mauvaises, parfois en temporisant avant même que je puisse me connecter. ssh n'est pas affecté. Je sais que c'est nginx car lorsque j'arrête nginx, le problème avec sftp disparaît instantanément. Cependant, nginx lui-même a essentiellement une latence nulle pendant ces "épisodes".
C'est un problème ancien avec mon serveur, et j'ai récemment décidé de m'en occuper une fois pour toutes. Hier, j'ai commencé à soupçonner que le simple volume de trafic http couplé à la latence plus élevée induite par un manque de bande passante amont empêchait mon trafic sftp. J'ai utilisé tc pour ajouter une certaine priorisation :
/sbin/tc qdisc add dev eth1 root handle 1: prio
/sbin/tc filter add dev eth1 protocol ip parent 1: prio 1 u32 match ip dport 22 0xffff flowid 1:1
/sbin/tc filter add dev eth1 protocol ip parent 1: prio 1 u32 match ip sport 22 0xffff flowid 1:1
/sbin/tc filter add dev eth1 protocol ip parent 1: prio 1 u32 match ip protocol 1 0xff flowid 1:1Malheureusement, même si je peux voir des paquets sftp s'accumuler dans la première priorité :
class prio 1:1 parent 1:
Sent 257065020 bytes 3548504 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class prio 1:2 parent 1:
Sent 291943287326 bytes 206538185 pkt (dropped 615, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class prio 1:3 parent 1:
Sent 22399809673 bytes 15525292 pkt (dropped 2334, overlimits 0 requeues 0)
backlog 0b 0p requeues 0 ... la latence est toujours inacceptable lors de la connexion. Voici quelques graphiques que j'ai faits récemment en essayant de corréler quelque chose avec la latence de sftp :
Voici la latence de sftp depuis un autre emplacement. J'ai défini le délai d'attente à 25 secondes. Tout ce qui est supérieur aux 1-2 secondes normaux qu'il faut pour se connecter et télécharger un petit fichier est inacceptable pour moi. Vous pouvez voir comment c'est correct la nuit puis la latence reprend pendant la journée.
Contenu de /proc/net/sockstat. Remarquez la corrélation apparente entre la latence de sftp et l'utilisation de la mémoire tcp. Aucune idée de ce que cela pourrait signifier.
Sortie du module stub-status de nginx. Rien à voir ici ...
Sortie de netstat -tan | awk '{print $6}' | sort | uniq -c. Encore une fois, semble plat.
Alors pourquoi tc ne fonctionne-t-il pas pour moi? Dois-je réellement limiter la bande passante plutôt que simplement prioriser le port 22 entrant et sortant? Ou est-ce que tc n'est pas l'outil approprié pour le travail et que j'ai complètement manqué la véritable cause des mauvaises performances de sftp?
Sortie de uname -a:
Linux [redacted] 3.2.0-0.bpo.2-amd64 #1 SMP Fri Jun 29 20:42:29 UTC 2012 x86_64 GNU/Linux
Je fais tourner nginx 1.2.2 avec le module de streaming mp4 compilé.
Édition du 31/07/2012 :
ewwhite a demandé si j'étais proche ou à ma limite de bande passante. J'ai vérifié, et il semble y avoir une corrélation (bien qu'imparfaite) entre la limite de 100 Mbit/s et la mauvaise latence de sftp :
Pourtant, pourquoi le trafic sftp (associé au port 22) ne serait-il pas prioritaire par rapport au trafic http pendant ces épisodes ?
Édition du 31/07/2012 #2
En collectant des données de latence sftp/scp, j'ai remarqué un schéma, comme le montre le graphique ci-dessous (les lignes vertes que j'ai ajoutées) :
Deux groupes - en soustrayant le "baseline" de la latence, ils sont à ~5 et ~10 secondes. Vous pouvez également les voir assez clairement sur le graphique de latence sftp ci-dessus sur une échelle de temps beaucoup plus grande. D'où vient ce chiffre de 5 secondes ?
