Scénario: Nous avons plusieurs clients Windows qui téléchargent régulièrement des fichiers volumineux (FTP / SVN / HTTP PUT / SCP) sur des serveurs Linux situés à environ 100 à 160 ms. Nous avons une bande passante synchrone de 1 Gbit / s au bureau et les serveurs sont des instances AWS ou hébergées physiquement dans des centres de distribution américains.
Le rapport initial indiquait que les téléchargements sur une nouvelle instance de serveur étaient beaucoup plus lents qu’ils ne le pourraient. Cela s'est avéré lors d'essais et à partir de plusieurs endroits; les clients voyaient une stabilité de 2 à 5 Mbit / s sur l'hôte à partir de leurs systèmes Windows.
J'ai éclaté iperf -s
sur une instance AWS puis à partir d'un client Windows du bureau:
iperf -c 1.2.3.4
[ 5] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 55185
[ 5] 0.0-10.0 sec 6.55 MBytes 5.48 Mbits/sec
iperf -w1M -c 1.2.3.4
[ 4] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 55239
[ 4] 0.0-18.3 sec 196 MBytes 89.6 Mbits/sec
Ce dernier chiffre peut varier considérablement lors de tests ultérieurs (variables de AWS), mais se situe généralement entre 70 et 130 Mbit / s, ce qui est largement suffisant pour répondre à nos besoins. En chargeant la session, je peux voir:
iperf -c
Windows SYN - Fenêtre 64 Ko, échelle 1 - Linux SYN, ACK: Fenêtre 14 Ko, Échelle: 9 (* 512)iperf -c -w1M
Windows SYN - Windows 64kb, échelle 1 - Linux SYN, ACK: fenêtre 14kb, échelle: 9
Il est clair que le lien peut supporter ce débit élevé, mais je dois définir explicitement la taille de la fenêtre pour pouvoir l'utiliser, ce que la plupart des applications du monde réel ne me permettent pas de faire. Les handshakes TCP utilisent les mêmes points de départ dans chaque cas, mais celui forcé
Réciproquement, à partir d’un client Linux sur le même réseau, un droit iperf -c
(en utilisant le système par défaut de 85 Ko) me donne:
[ 5] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 33263
[ 5] 0.0-10.8 sec 142 MBytes 110 Mbits/sec
Sans forcer, il évolue comme prévu. Cela ne peut pas être quelque chose dans les sauts ou nos commutateurs / routeurs locaux et semble affecter les clients Windows 7 et 8. J'ai lu de nombreux guides sur le réglage automatique, mais ceux-ci concernent généralement la désactivation de la mise à l'échelle pour contourner le mauvais kit de réseau domestique.
Quelqu'un peut-il me dire ce qui se passe ici et me donner un moyen de le réparer? (De préférence, je peux me connecter au registre via GPO.)
Remarques
Les paramètres de noyau suivants sont appliqués dans l'instance AWS Linux en question sysctl.conf
:
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.rmem_default = 1048576
net.core.wmem_default = 1048576
net.ipv4.tcp_rmem = 4096 1048576 16777216
net.ipv4.tcp_wmem = 4096 1048576 16777216
J'ai utilisé la dd if=/dev/zero | nc
redirection vers /dev/null
le serveur pour iperf
éliminer et éliminer tous les goulots d'étranglement possibles, mais les résultats sont sensiblement les mêmes. Les tests avec ncftp
(Cygwin, Windows natif, Linux) s’effectuent de la même manière que les tests iperf ci-dessus sur leurs plates-formes respectives.
Modifier
J'ai remarqué une autre chose cohérente ici qui pourrait être pertinente:
Il s’agit de la première seconde de la capture de 1 Mo agrandie. Vous pouvez voir le démarrage lent en action à mesure que la fenêtre s’agrandit et que la mémoire tampon s’agrandit. Il y a ensuite ce petit plateau de ~ 0,2s exactement au point où le test iperf par défaut de la fenêtre s’aplatit pour toujours. Celui-ci évolue bien sûr jusqu'à des hauteurs beaucoup plus vertigineuses, mais il est curieux qu'il y ait une pause dans la mise à l'échelle (les valeurs sont de 1022 octets * 512 = 523264) avant de le faire.
Mise à jour - 30 juin.
Suivi des différentes réponses:
- Activer le CTCP - Cela ne fait aucune différence. la mise à l'échelle de la fenêtre est identique. (Si je comprends bien, ce paramètre augmente la vitesse à laquelle la fenêtre d’encombrement est agrandie plutôt que la taille maximale qu’elle peut atteindre)
- Activation des horodatages TCP. - Pas de changement ici non plus.
- Algorithme de Nagle - Cela a du sens et au moins, cela signifie que je peux probablement ignorer ce blips particulier dans le graphique comme une indication du problème.
- Fichiers pcap: Le fichier Zip est disponible ici: https://www.dropbox.com/s/104qdysmk01lnf6/iperf-pcaps-10s-Win%2BLinux-2014-06-30.zip (anonymisé avec bittwiste, extraits à ~ 150 Mo comme indiqué ci-dessous. un de chaque client OS pour la comparaison)
Mise à jour 2 - 30 juin
O, donc après la suggestion de Kyle, j'ai activé ctcp et désactivé le déchargement de cheminées: Paramètres globaux TCP
----------------------------------------------
Receive-Side Scaling State : enabled
Chimney Offload State : disabled
NetDMA State : enabled
Direct Cache Acess (DCA) : disabled
Receive Window Auto-Tuning Level : normal
Add-On Congestion Control Provider : ctcp
ECN Capability : disabled
RFC 1323 Timestamps : enabled
Initial RTO : 3000
Non Sack Rtt Resiliency : disabled
Mais malheureusement, aucun changement dans le débit.
J'ai cependant une question de cause à effet ici: les graphiques correspondent à la valeur RWIN définie dans les ACK du serveur adressés au client. Avec les clients Windows, ai-je raison de penser que Linux ne redimensionne pas cette valeur au-delà de ce point bas, car le CWIN limité du client empêche même le remplissage de cette mémoire tampon? Pourrait-il y avoir une autre raison pour laquelle Linux limite artificiellement le RWIN?
Remarque: j'ai essayé d'allumer ECN pour le plaisir. mais pas de changement, là-bas.
Mise à jour 3 - 31 juin.
Aucune modification après la désactivation des heuristiques et du réglage automatique RWIN. Avoir mis à jour les pilotes de réseau Intel avec la dernière version (12.10.28.0) avec un logiciel exposant les onglets de la fonctionnalité ajustés au gestionnaire de viadevice. La carte est une carte réseau intégrée au jeu de puces 82579V - (je vais faire d'autres tests avec des clients de realtek ou d'autres fournisseurs)
En me concentrant un instant sur la carte réseau, j'ai essayé les solutions suivantes (principalement en éliminant les coupables improbables):
- Augmentez le nombre de tampons de réception de 256 à 2k et passez de 512 à 2k les tampons de transmission (les deux sont désormais au maximum) - Aucune modification.
- Désactiver tout le déchargement de la somme de contrôle IP / TCP / UDP. - Pas de changement.
- Désactivé Large envoi Déchargement - Nada.
- Désactivé IPv6, planification QoS - Maintenant.
Mise à jour 3 - 3 juillet
En essayant d'éliminer le côté serveur Linux, j'ai démarré une instance de Server 2012R2 et répété les tests en utilisant iperf
(cygwin binary) et NTttcp .
Avec iperf
, je devais préciser explicitement -w1m
sur les deux côtés avant que la connexion escaladeraient au - delà de ~ 5Mbit / s. (Incidemment, je pourrais être vérifié et le BDP de ~ 5 Mbits à une latence de 91 ms est presque à 64 kb. Trouvez la limite ...)
Les fichiers binaires ntttcp ont maintenant montré une telle limitation. En utilisant ntttcpr -m 1,0,1.2.3.5
sur le serveur et ntttcp -s -m 1,0,1.2.3.5 -t 10
sur le client, je peux voir un débit bien meilleur:
Copyright Version 5.28
Network activity progressing...
Thread Time(s) Throughput(KB/s) Avg B / Compl
====== ======= ================ =============
0 9.990 8155.355 65536.000
##### Totals: #####
Bytes(MEG) realtime(s) Avg Frame Size Throughput(MB/s)
================ =========== ============== ================
79.562500 10.001 1442.556 7.955
Throughput(Buffers/s) Cycles/Byte Buffers
===================== =========== =============
127.287 308.256 1273.000
DPCs(count/s) Pkts(num/DPC) Intr(count/s) Pkts(num/intr)
============= ============= =============== ==============
1868.713 0.785 9336.366 0.157
Packets Sent Packets Received Retransmits Errors Avg. CPU %
============ ================ =========== ====== ==========
57833 14664 0 0 9.476
8Mo / s met en hausse au niveau que je recevais avec des fenêtres explicitement dans les grandes iperf
. Bizarrement, cependant, 80 Mo sur 1273 mémoires tampon = une mémoire tampon de 64 Ko à nouveau. Une autre liste de fils montre un bon RWIN variable renvoyé par le serveur (facteur d'échelle 256) que le client semble remplir; alors peut-être que ntttcp fait une mauvaise déclaration de la fenêtre d'envoi.
Mise à jour 4 - 3 juillet
À la demande de @ karyhead, j'ai effectué d'autres tests et généré quelques captures supplémentaires, à l' adresse suivante : https://www.dropbox.com/s/dtlvy1vi46x75it/iperf%2Bntttcp%2Bftp-pcaps-2014-07-03.zip
- Deux secondes supplémentaires
iperf
, toutes deux de Windows vers le même serveur Linux qu'auparavant (1.2.3.4): une avec une taille de socket de 128 Ko et une fenêtre par défaut de 64 Ko (limitée à environ 5 Mbit / s) et une avec une fenêtre d'envoi de 1 Mo et un socket de 8 Ko par défaut Taille. (échelles plus élevées) - Une
ntttcp
trace du même client Windows vers une instance Server 2012R2 EC2 (1.2.3.5). ici, le débit varie bien. Remarque: NTttcp fait quelque chose d'étrange sur le port 6001 avant d'ouvrir la connexion de test. Pas sûr de ce qui se passe là-bas. - Une trace de données FTP, en téléchargeant 20 Mo
/dev/urandom
sur un hôte Linux presque identique (1.2.3.6) à l’aide de Cygwinncftp
. Encore une fois la limite est là. Le schéma est sensiblement le même avec Windows Filezilla.
La modification de la iperf
longueur de la mémoire tampon fait toute la différence attendue par rapport au graphe de séquence dans le temps (sections beaucoup plus verticales), mais le débit réel reste inchangé.
netsh int tcp set global timestamps=enabled