Pourquoi le débit de transfert SMB est-il si bas?

Ok, il y a un peu plus dans l'histoire que le titre l'indique.

Contexte et environnement : je copie plusieurs To d'un ancien serveur Ubuntu vers un nouveau serveur Windows 2012 sur SMB. (Techniquement, c'est du matériel de base, mais ce sont des serveurs ici.) Tout le monde est sur un réseau local gigabit, et l'ancienne boîte Ubuntu a une interface liée. Je crois que le serveur Ubuntu a deux cartes Ethernet Rosewill PCI-e 1x et le serveur Windows a une carte Ethernet Intel PCI assez agréable.

L'ordinateur de destination (le serveur Windows) exécute un pool de stockage avec parité sur 4 lecteurs de 2 To. Il exécute le nouveau ReFS de Microsoft. L'ordinateur source (le serveur Ubuntu) exécute un miroir RAID logiciel. Il fonctionne bien ol 'EXT4.

Les deux serveurs fonctionnent via un seul commutateur gigabit. J'ai expérimenté la rupture de la liaison sur l'ordinateur source (Ubuntu) sans aucune amélioration.

Problème : je n'ai aucun problème à transférer à des vitesses raisonnables d'autres ordinateurs vers le serveur Windows. D'autres ordinateurs peuvent contenir 50 à 80 Mo / s sans trop de difficultés, mais le transfert à partir de ce serveur Ubuntu ne dépasse pas 20 Mo / s. 4 + TB à 20 Mo / s prennent beaucoup de temps (quelque chose comme 2,3 jours), et je me demande ce que je peux faire pour déterminer où se trouve le goulot d'étranglement.

Symptômes : le processeur sur les deux ordinateurs est assez minime et certainement pas trop occupé. Les disques durs sur les deux ordinateurs sont actifs mais pas submergés, et le processeur IOwait est près de 0% sur au moins le serveur Ubuntu.

J'ai fait une trace Wireshark pendant 35 secondes (probablement assez longtemps pour m'assurer que tous les ACK étaient destinés à de nouveaux paquets) et j'ai remarqué qu'il y avait pas mal de choses auxquelles je ne m'attendais pas. (1) Il n'y avait aucune somme de contrôle pour les ACK (et certains paquets SMB) de Windows à Ubuntu. Cependant, Wireshark affirme que cela peut être dû au «déchargement de la somme de contrôle IP». Ok, j'ai une jolie carte là-dedans. Je suppose qu'il est possible que la carte réseau fasse des calculs de somme de contrôle. Bien. Passons à autre chose ... (2) "Segment invisible TCP TCP". Celui-ci, j'ai un problème. Le numéro ACK est dans une plage acceptable de ce que je peux dire, et il y a souvent d'énormes blocs de ces messages. Peut-être que Wireshark est tout simplement trop lent?

Résumé : La vitesse de transfert est nulle (20 Mo / s sur Gigabit Ethernet) et je ne sais pas pourquoi. Wireshark affirme que Windows ACKe des choses qui n'ont jamais été envoyées par Ubuntu.

Devinez : Ma première supposition est que les cartes Rosewill moins chères sont submergées. Ma deuxième supposition est que les choses de type RAID logiciel à une extrémité ou à l'autre sont inondées de choses à faire.

Votre écart de performances correspond à une expérience courante lorsque Samba (pas sûr que ce soit toujours la valeur par défaut; c'était pendant longtemps) est configuré avec la taille par défaut du tampon de socket de lecture et d'écriture de 1024 octets.

J'avais l'habitude de voir cela fréquemment avec les machines Linux et Mac. Espérons que ce ne soit pas encore le cas.

Il y a un argument d'option de socket dans le fichier de configuration de samba où vous pouvez définir la taille du tampon de socket de lecture et d'écriture. Vous suggère de définir les deux à 8192 octets (8 Ko). 4 ou 8 Ko est souvent similaire, mais je ne l'ai pas testé sur un lien gigabit.

De plus, ne vous attendez pas à ce qu'une seule connexion TCP bénéficie d'une liaison liée, le trafic passera presque toujours par l'une des liaisons; sinon, vous vous retrouvez avec beaucoup de paquets en panne à traiter; attendez-vous donc uniquement à un avantage d'équilibrage de charge lors de la maintenance de plusieurs clients. Même dans ce cas, vous devez rechercher les différents modes de liaison et savoir que pour au moins la liaison "mode 4" (IEEE 802.3ad), il existe essentiellement deux modes de hachage de transmission, qui déterminent sur quelle interface esclave envoyer. Il existe un hachage de couche 2 (par défaut) et un hachage de couche 3. Si vous envoyez la majeure partie de vos données via la passerelle, le hachage de couche 2 ne se distribuera pas correctement, car l'adresse MAC de la passerelle sera la même. Envisagez plutôt d'utiliser la couche 3.

Une fois, j'avais deux cartes Ethernet dans un ordinateur Ubuntu et pour une raison quelconque, cela ne fonctionnait pas correctement - ils rivalisaient tous les deux pour les mêmes paquets, donc parfois j'obtiendrais une réponse parfois je ne le ferais pas, selon que l'autre carte réseau attrapait les emballés. C'était étrange. J'ai dû l'avoir mal configuré d'une manière ou d'une autre, mais j'aurais pensé qu'il aurait simplement fonctionné. Les cartes avaient bien sûr des adresses IP uniques.

Quoi qu'il en soit, il serait simple pour vous de l'essayer avec une seule carte Ethernet dans la machine connectée au réseau juste pour exclure cela.