Pourquoi y a-t-il une différence de vitesse d'écriture entre dd, cp, rsync et macOS Finder sur un lecteur SMB3?

Tl; dr - Nous ne pouvons pas trouver la raison de la vitesse d'écriture limitée de 60 Mo / s sur notre NAS via SMB et AFP à partir de deux clients Mac différents. En comparaison: un vieil ordinateur portable Windows 7 sur le même réseau écrit 100 Mo / sec.

Si vous lisez cette question pour la première fois, veuillez passer à la section Mise à jour 4 . rsyncest la principale raison de la faible vitesse, même si nous ne comprenons pas pourquoi (pour un seul fichier!).

Question d'origine: trouver un goulot d'étranglement SMB3 / NAS avec Mac OS 10.11.5 et supérieur

Nous avons testé via rsync --progress -a /localpath/test.file /nas/test.filesur macOS et les informations de copie de Windows.

Le NAS est un DS713 + exécutant leur DSM 6.0.2 actuel (testé avec 5.x également), avec deux NAS HGST Deskstar SATA 4TB (HDN724040ALE640) en RAID1 avec uniquement des composants Ethernet gigabit et de nouveaux câbles Ethernet (au moins Cat5e).

Les clients Mac n'ont d'abord fait que 20 Mo / sec. Mais en appliquant le signing_required=nocorrectif (décrit ici ) a poussé la vitesse d'écriture à 60 Mo / s via SMB2 et SMB3. L'AFP délivre également environ 60 Mo / sec. Le résultat varie autour de 5 Mo / sec selon le protocole et le client (Mac).

Ce que nous avons déjà essayé:

Réseau

1. Test des performances du réseau via iperf3. Résultat: 926 Mbit / s. Cela semble bon.
2. Interfaces réseau d'agrégation / de liaison double éprouvées. Pas de changement.
3. MTU augmenté à 6000 et 9000. Aucun changement.
4. Vérifié tous les câbles. Très bien au moins Cat5e, en bon état.

Disques

1. Vérifié SMART Semble sain.
2. Testé vitesse d'écriture directement sur le disque avec dd if=/dev/zero of=write.test bs=256M count=4avec divers bset countparamètres (128/8, 512M / 2, 1024/1). Résultat: environ 120 Mo / s (selon la taille / le nombre de blocs)

SMB / AFP

1. Comparés SMB2, SMB3 et AFP les uns contre les autres. À peu près égal.
   Voir la mise à jour ci-dessous: Mauvaise méthode utilisée pour exclure l'implémentation SMB de macOS. SMB sur Windows est plus rapide, les nouveaux paramètres SMB fournis avec macOS 10.11 et 10.12 peuvent en être la raison.
2. J'ai essayé de modifier les paramètres SMB, y compris les options de socket (en suivant cette instruction )
3. J'ai essayé une version différente des paramètres d'acquit différé et rsync --sockopts=TCP_NODELAY(commentaires)

Aucun changement significatif de la vitesse d'écriture. Nous avons revérifié que la configuration était vraiment chargée et nous éditions le bon smb.conf .

Système

1. Charge CPU et RAM observée. Rien ne dépasse. CPU environ 20%, RAM environ 25% pendant le transfert.
2. Testé le même NAS avec DSM 5.xx dans une configuration presque prête à l'emploi. Aucun logiciel supplémentaire installé. Remarque: nous en avons deux à différents endroits. Ils sont synchronisés via CloudSync de Synology. Même résultat.
3. Désactivez tout ce qui n'est pas nécessaire et qui pourrait puiser des ressources système.

Nous pensons que c'est une configuration plutôt par défaut, pas d'adaptations sophistiquées, de clients ou de composants réseau. Selon les statistiques publiées par Synology, le NAS devrait accélérer de 40 Mo / s à 75 Mo / s. Mais nous ne pouvons tout simplement pas trouver le goulot d'étranglement.

Clients / NAS

Les clients Mac sont un MacPro 5,1 (carte réseau câblée standard, exécutant 10.12.3 (16D32)) et un MacBookPro10,1 (adaptateur réseau Thunderbolt, exécutant 10.11.6) à seulement 2 m de câble du NAS, fonctionnant sur le même commutateur gigabit comme ordinateur portable Windows dans le test.

Nous avons deux de ces NAS à différents endroits et les résultats sont identiques. Les secondes NAS sont plus ou moins par défaut (même pas de logiciel tiers installé). Juste deux disques au format RAID1, EXT4 se synchronisant avec l'autre NAS via Synology CloudSync. Nous sommes allés jusqu'à nous connecter directement au NAS sans le commutateur, même résultat.

Mise à jour importante

La méthode utilisée pour exclure l'implémentation SMB de macOS / OS X était incorrecte. Je l'ai testé via une machine virtuelle, en supposant qu'il utiliserait sa propre version de SMB, mais évidemment le trafic est transféré à macOS, passant par sa version de SMB.

En utilisant un ordinateur portable Windows, j'ai maintenant pu atteindre une moyenne de 100 Mo / s. L'indication de l'implémentation / mise à jour SMB fournie avec 10.11 et 10.12 peut entraîner des performances médiocres. Même si signing_requiredest réglé sur no.

Ce serait formidable si quelqu'un pouvait signaler d'autres paramètres qui pourraient avoir changé avec les mises à jour et affecter les performances.

Mise à jour 2 - nouvelles perspectives

AndrewHenle a souligné dans les commentaires que je devais étudier le trafic en détail en utilisant Wireshark pour plus d'informations.

J'ai donc couru sudo tcpdump -i eth0 -s 65535 -w tcpdump.dumpsur le NAS, tout en transférant deux fichiers de test l'un avec 512 Mo et l'autre avec 1 Go. Et inspecté le dépotoir avec Wireshark.

Ce que j'ai trouvé:

1. OS X et Windows semblent utiliser SMB2 bien que SMB3 soit activé sur le NAS (au moins selon Wireshark).
2. OS X semble s'en tenir au MTU . Les paquets ont 1514 octets, ce qui augmente considérablement la surcharge du réseau et les paquets envoyés (visibles dans les vidages).
3. Windows semble envoyer des paquets jusqu'à 26334 octets (si je lis correctement les données! Veuillez vérifier.) Même si le MTU ne devrait pas permettre cela, car il est réglé sur 1500 sur le NAS, le paramètre maximum serait de 9000 (Synology aussi utilise le paramètre 1500 dans leurs tests).
4. Essayer de forcer macOS à utiliser SMB3 en ajoutant smb_neg=smb3_onlyau /etc/nsmb.conf n'a pas fonctionné ou au moins n'a pas conduit à des transferts plus rapides.
5. L'exécution rsync --sockopts=TCP_NODELAYavec diverses combinaisons de paramètres d'acquittement différé TCP (0 à 3) n'a eu aucun effet (Remarque: j'ai exécuté le tcpdump avec le paramètre d'acquittement par défaut de 3).

J'ai créé 4 vidages sous forme de fichiers .csv, 2 lors de la copie de 512 Mo (test-2.file) et 2 lors de la copie de 1024 Mo (test.file). Vous pouvez télécharger les exportations Wireshark ici (25,2 Mo). Ils sont zippés pour économiser de l'espace et nommés de manière explicite.

Mise à jour 3 - sortie smbutil

Sortie de smbutil statshares -acomme demandé par harrymc dans les commentaires.

==================================================================================================
SHARE                         ATTRIBUTE TYPE                VALUE
==================================================================================================
home
                              SERVER_NAME                   server-name._smb._tcp.local
                              USER_ID                       502
                              SMB_NEGOTIATE                 SMBV_NEG_SMB1_ENABLED
                              SMB_NEGOTIATE                 SMBV_NEG_SMB2_ENABLED
                              SMB_NEGOTIATE                 SMBV_NEG_SMB3_ENABLED
                              SMB_VERSION                   SMB_3.0
                              SMB_SHARE_TYPE                DISK
                              SIGNING_SUPPORTED             TRUE
                              EXTENDED_SECURITY_SUPPORTED   TRUE
                              LARGE_FILE_SUPPORTED          TRUE
                              OS_X_SERVER                   TRUE
                              QUERYINFO_NOT_SUPPORTED       TRUE
                              DFS_SUPPORTED                 TRUE
                              MULTI_CREDIT_SUPPORTED        TRUE

--------------------------------------------------------------------------------------------------

Remarque à ce sujet: je suis sûr SIGNING_SUPPORTEDqu'être trueici ne signifie pas que le paramètre dans la configuration ne fonctionne pas. Mais seulement qu'il est pris en charge par le NAS. J'ai vérifié que changer lasigning_required paramètre dans ma configuration a un effet sur la vitesse d'écriture (~ 20 Mo / s lorsqu'il est allumé, ~ 60 Mo / s lorsqu'il est éteint).

Mise à jour 4 - Samba Wars: un nouvel espoir

Cela semble quelque peu gênant, mais le problème principal ici - encore une fois - semble être la mesure.

S'avère rsync --progress -acoûte environ 30 Mo / s de vitesse d'écriture. Écrire avec dddirectement sur le partage SMB et utilisertime cp /local/test.file /NAS/test.file sont plus rapides à environ 85-90 Mo / s et apparemment le moyen le plus rapide pour copier est le Finder macOS à environ 100 Mo / s (qui est également la méthode la plus difficile à mesurer, car il n'y a pas indicateur de synchronisation ou de vitesse - qui en a besoin, non? o_O). Nous l'avons mesuré en copiant d'abord un fichier de 1 Go puis un fichier de 10 Go, à l'aide d'un chronomètre.

Ce que nous avons essayé depuis la dernière mise à jour de cette question.

1. Copiez du client Mac vers le client Mac. Les deux ont des SSD (MacPro écrit avec 250 Mo / s sur son propre disque, MacBook Pro avec 300 Mo / s). Résultat: un maigre 65 Mo / s via l' ddécriture de MacBook Pro vers MacPro (rsync 25 Mo / s). Voir les 25 Mo / s était le moment où nous avons commencé à remettre en question rsync. 65 Mo / s sont encore extrêmement lents. Ainsi, l'implémentation SMB sur macOS semble… enfin, discutable.
2. J'ai essayé différents paramètres d'ack avec dd et cp - pas de chance.
3. Enfin, nous avons trouvé un moyen de répertorier toutes les options nsmb.conf disponibles. C'est simple man nsmb.conf. Attention, la version en ligne est obsolète!

Nous avons donc essayé quelques paramètres supplémentaires, parmi eux:

notify_off=yes
validate_neg_off=yes
read_async_cnt=16
write_async_cnt=16
dir_cache_async_cnt=40
protocol_vers_map=4
streams=no
soft=yes

Remarque: smb_neg=smb3_onlyn'est pas - comme je m'y attendais déjà - un paramètre valide. protocol_vers_map=4devrait être l'équivalent valide.

Quoi qu'il en soit, aucun de ces paramètres n'a fait de différence pour nous.

Nouvelles questions en un coup d'œil

1. Pourquoi rsync est-il un moyen si coûteux de copier un (1!) Fichier. Il n'y a pas grand-chose à synchroniser / comparer ici, n'est-ce pas? Le tcpdump n'indique pas non plus une surcharge possible.

2. Pourquoi ddet cpplus lent que le Finder macOS lors du transfert vers un partage SMB? Il semble que lors de la copie avec le Finder, il y ait beaucoup moins d'acquittements dans la communication TCP. (Encore une fois: le paramètre d'ack, par exemple, delayed_ack=1n'a fait aucune différence pour nous.)

3. Pourquoi Windows semble-t-il ignorer le MTU, envoyant des paquets TCP beaucoup plus gros et donc moins, ce qui donne les meilleures performances, par rapport à tout ce qui est possible via macOS.

Voici à quoi ressemblent les paquets de macOS (constamment 1514)

"TCP","1514","[TCP segment of a reassembled PDU]"
"TCP","66","445  >  56932 [ACK] Seq=6603 Ack=35239 Win=4505 Len=0 TSval=520980697 TSecr=650208630"

Et cela venant de Windows (jusqu'à 26334, de taille variable)

"SMB2","1466","Write Request Len:65536 Off:196608 File: test.file"
"TCP","26334","[TCP segment of a reassembled PDU]"
"TCP","7354","[TCP segment of a reassembled PDU]"
"TCP","54","445  >  49220 [ACK] Seq=6831 Ack=267030 Win=4074 Len=0"

Vous pouvez télécharger le fichier .csv complet ici (25,2 Mo), les noms de fichiers expliquent ce qui a été copié (système d'exploitation, méthode de transfert et taille du fichier).

1. question similaire mais a des réponses intéressantes, peut-être vous pouvez vérifier ce fil en particulier sur le commentaire 5: https://bugzilla.samba.org/show_bug.cgi?id=8512#c5

Citez ici "Peter van Hooft". Bien que je ne sois pas sûr de tester la base sur quoi / quelle dist linux. et la version de rsync aussi. Cependant: 1. il nous donne une idée d'essayer --sparse flag si possible pour augmenter les performances. 2. il a testé sur le protocole NFS mais a rencontré le même problème de vitesse, donc, ce n'est peut-être pas la raison du protocole (SMB2 / 3, AFP, etc.).

Nous utilisons rsync pour copier des données d'un serveur de fichiers à un autre à l'aide de montages NFS3 sur une liaison 10 Go . Nous avons constaté que l'augmentation des tailles de tampon (comme test rapide) augmente les performances. Lorsque vous utilisez --sparse, cela augmente les performances avec un facteur de cinquante, de 2MBps à 100MBps.

2. Voici une autre inspection intéressante des performances de rsync. https://lwn.net/Articles/400489/

LWN.net a conclu que le problème de performances peut concerner le noyau, même l'article publié en 2010 et que nous ne pouvons pas changer sur NAS ou MacOS. Cependant, cet article nous donne une idée que le problème du noyau peut être causé par le calcul de la somme de contrôle (je suppose).

Une chose est claire: je devrais mettre à jour le noyau de mon système Mythtv. En général, les noyaux 2.6.34 et 2.6.35-rc3 donnent de meilleures performances que l'ancien noyau 2.6.27. Mais, bricolage ou non, rsync ne peut toujours pas battre un simple cp qui copie à plus de 100 Mo / s. En effet, rsync a vraiment besoin de beaucoup de puissance CPU pour de simples copies locales. À la fréquence la plus élevée, cp n'a eu besoin que de 0,34 + 20,95 secondes de temps processeur, contre 70 + 55 secondes pour rsync.

citer également des commentaires a ceci:

Notez que rsync vérifie toujours que chaque fichier transféré a été correctement reconstruit du côté réception en vérifiant une somme de contrôle de fichier entier qui est générée lors du transfert du fichier

mise à jour 1 : mon erreur, cette description est pour --checksum. vérifiez-le ici: [Amélioration de la description de l'option --checksum.] PS, je n'ai pas assez de réputation pour poster plus de 2 liens.

mais je ne trouve pas la même description sur la page de manuel de rsync, donc je suppose que quelqu'un parle ci-dessous en gras:

Rsync recherche les fichiers qui doivent être transférés à l'aide d'un algorithme de "vérification rapide" (par défaut) qui recherche les fichiers dont la taille ou la dernière modification ont changé. Toute modification des autres attributs préservés (comme demandé par les options) est effectuée directement sur le fichier de destination lorsque la vérification rapide indique que les données du fichier n'ont pas besoin d'être mises à jour.

Par conséquent, comparez-le à cp / tar / cat, si nous utilisons rsync pour copier des tas de petits ou gros fichiers, cela pourrait entraîner des problèmes de performances. MAIS en raison de l'impossibilité de lire le code source de rsync, je ne peux donc pas confirmer que c'est la raison ultime.

mon idée est de continuer à vérifier:

1. Quelle version de rsync utilise awenro pour les tests? Pourriez-vous mettre à jour vers la dernière version?
2. voyons quelle sortie utiliser --stats et -v avec --debug = FLAGS

drapeaux

--stats Ceci indique à rsync d'imprimer un ensemble détaillé de statistiques sur le transfert de fichiers, vous permettant de déterminer l'efficacité de l'algorithme rsync pour vos données.

--debug = FLAGS Cette option vous permet d'avoir un contrôle précis sur la sortie de débogage que vous souhaitez voir. Un nom d'indicateur individuel peut être suivi d'un numéro de niveau, 0 signifiant pour mettre cette sortie sous silence, 1 étant le niveau de sortie par défaut, et des nombres plus élevés augmentant la sortie de cet indicateur (pour ceux qui prennent en charge les niveaux supérieurs). Utilisez --debug = help pour voir tous les noms d'indicateurs disponibles , ce qu'ils produisent et quels noms d'indicateurs sont ajoutés pour chaque augmentation du niveau détaillé.

à la fin, je recommanderais de lire ce post supplémentaire pour obtenir plus de connaissances.
"Comment transférer de grandes quantités de données via le réseau" moo.nac.uci.edu/~hjm/HOWTO_move_data.html

Rsync / ssh crypte la connexion que smb ne fait pas, si je me souviens bien. S'il ne s'agit que d'un seul fichier, un système pourra peut-être lire ce fichier et l'autre pas. Notez également que pour avoir une MTU supérieure à 1514, vous devez activer les paquets "géants" / "Jumbo Frames", le fait que les paquets doivent être encore réduits peut impliquer qu'il y a un surcoût pour "reconditionner" le paquet. La deuxième chose à noter est que les "géants" / "Jumbo Frames" doivent être activés aux deux extrémités ET TOUT ENTRE.

1514 correspond aux trames Ethernet normales. Les cadres 6k-9k sont appelés géants ou "Jumbo Frames" selon le système d'exploitation / l'application

Je fais en moyenne 80 Mo / s entre mon NAS (un PC avec des VM, l'une des VM est le NAS) et ma station (un PC) avec sftp (en utilisant sshfs) [géants non activés] et l'appareil entre les deux est un microtik 2011 (va puce commutateur tru uniquement)

N'oubliez pas que le MTU est négocié entre deux points et que le long d'un chemin, vous pouvez avoir plusieurs MTU à des capacités différentes et que le MTU sera le plus bas disponible.

edit: SMB n'est pas très efficace pour les transferts de fichiers.