Tl; dr - Wir können den Grund für die begrenzte Schreibgeschwindigkeit von 60 MB / s auf unseren NAS über SMB und AFP von zwei verschiedenen Mac-Clients nicht finden. Zum Vergleich: Ein alter Windows 7-Laptop im selben Netzwerk schreibt konstant 100 MB / s.
Wenn Sie diese Frage zum ersten Mal lesen, fahren Sie mit dem Abschnitt Update 4 fort . rsyncist der Hauptgrund für die niedrige Geschwindigkeit, obwohl wir nicht verstehen, warum (für eine einzelne Datei!).
Originalfrage: Finden Sie einen Geschwindigkeitsengpass für SMB3 / NAS mit Mac OS 10.11.5 und höher
Wir haben via rsync --progress -a /localpath/test.file /nas/test.fileauf macOS und die Kopierinfo von Windows getestet .
Der NAS ist ein DS713 + mit dem aktuellen DSM 6.0.2 (auch mit 5.x getestet) und zwei HGST Deskstar NAS SATA 4 TB (HDN724040ALE640) in RAID1 mit nur Gigabit-Ethernet-Komponenten und neuen Ethernet-Kabeln (mindestens Cat5e).
Mac-Clients machten zunächst nur 20 MB / s. Durch Anwenden des hiersigning_required=no beschriebenen Fix wurde die Schreibgeschwindigkeit über SMB2 und SMB3 auf 60 MB / s erhöht. AFP liefert auch rund 60 MB / Sek. Das Ergebnis variiert je nach Protokoll und (Mac-) Client um 5 MB / s.
Was wir schon ausprobiert haben:
Netzwerk
- Getestete Netzwerkleistung über iperf3. Ergebnis: 926 Mbit / s. Sieht gut aus.
- Versuchte Dual Link Aggregation / Bonded Network Interfaces. Keine Änderung.
- MTU auf 6000 und 9000 erhöht. Keine Änderung.
- Alle Kabel überprüft. Alles in Ordnung, zumindest Cat5e, in gutem Zustand.
Festplatten
- Checked SMART Sieht gesund aus.
- Getestet Schreibgeschwindigkeit direkt auf die Festplatte mit
dd if=/dev/zero of=write.test bs=256M count=4mit verschiedenenbsundcountEinstellungen (128/8, 512M / 2, 1024/1). Ergebnis: ca. 120 MB / s (abhängig von Blockgröße / Anzahl)
SMB / AFP
Vergleich von SMB2, SMB3 und AFP. Ungefähr gleich.
Siehe Update unten: Falsche Methode zum Ausschließen der SMB-Implementierung von macOS. SMB unter Windows ist schneller, neue SMB-Einstellungen unter MacOS 10.11 und 10.12 sind möglicherweise der Grund.- Versucht, die SMB-Einstellungen zu optimieren, einschließlich der Socket-Optionen (gemäß dieser Anleitung )
- Versuchte andere Version der verzögerten Bestätigungseinstellungen und
rsync --sockopts=TCP_NODELAY(Kommentare)
Keine wesentliche Änderung der Schreibgeschwindigkeit. Wir haben doppelt überprüft, ob die Konfiguration wirklich geladen ist und wir haben die richtige smb.conf bearbeitet .
System
- Überwachte CPU- und RAM-Auslastung. Nichts geht über die Maßen. CPU ca. 20%, RAM ca. 25% während der Übertragung.
- Testete den gleichen NAS mit DSM 5.xx in einem fast sofort einsatzbereiten Setup. Keine zusätzliche Software installiert. Hinweis: Wir haben zwei davon an verschiedenen Standorten. Sie sind über CloudSync von Synology synchronisiert. Gleiches Ergebnis.
- Deaktiviert alles Unnötige, was Systemressourcen beanspruchen könnte.
Wir denken, dass dies ein eher Standard-Setup ist, keine ausgefallenen Anpassungen, Clients oder Netzwerkkomponenten. Nach den von Synology veröffentlichten Metriken sollte der NAS 40 MB / s bis 75 MB / s schneller sein. Aber wir können den Engpass einfach nicht finden.
Clients / NAS
Bei den Mac-Clients handelt es sich um einen MacPro 5,1 (standardmäßige verkabelte Netzwerkkarte mit 10.12.3 (16D32)) und einen MacBookPro 10,1 (Thunderbolt-Netzwerkadapter mit 10.11.6), die nur etwa 2 m vom NAS entfernt sind und über dasselbe Kabel laufen Gigabit-Switch als Windows-Laptop im Test.
Wir haben zwei dieser NAS an verschiedenen Standorten und die Ergebnisse sind identisch. Der Sekunden-NAS ist mehr oder weniger werkseitig voreingestellt (nicht einmal Software von Drittanbietern installiert). Nur zwei mit RAID1, EXT4 formatierte Festplatten werden über Synology CloudSync mit dem anderen NAS synchronisiert. Wir sind so weit gegangen, eine direkte Verbindung mit dem NAS ohne den Switch herzustellen, dasselbe Ergebnis.
Wichtiges Update
Die Methode zum Ausschließen der SMB-Implementierung von macOS / OS X war falsch. Ich habe es über eine virtuelle Maschine getestet, unter der Annahme, dass es eine eigene Version von SMB verwenden würde, aber der Datenverkehr wird offensichtlich an macOS weitergeleitet und läuft über die Version von SMB.
Mit einem Windows-Laptop konnte ich jetzt durchschnittlich 100 MB / s erreichen. Das Anzeigen der SMB-Implementierung / -Updates in 10.11 und 10.12 kann zu einer schlechten Leistung führen. Auch wenn auf gesetzt signing_requiredist no.
Wäre toll, wenn jemand auf weitere Einstellungen hinweisen könnte, die sich mit den Updates möglicherweise geändert haben und die Leistung beeinträchtigen könnten.
Update 2 - neue Erkenntnisse
AndrewHenle wies in den Kommentaren darauf hin, dass ich den Verkehr mit Wireshark detaillierter untersuchen sollte, um mehr Einsichten zu erhalten.
Ich lief daher sudo tcpdump -i eth0 -s 65535 -w tcpdump.dumpauf dem NAS, während ich zwei Testdateien übertrug, eine mit 512 MB und eine mit 1 GB. Und inspizierte die Müllhalde mit Wireshark.
Was ich fand:
- Sowohl OS X als auch Windows scheinen SMB2 zu verwenden, obwohl SMB3 auf dem NAS aktiviert ist (zumindest laut Wireshark).
- OS X scheint bei der MTU zu bleiben . Die Pakete haben 1514 Bytes, was zu mehr Netzwerk-Overhead und gesendeten Paketen führt (sichtbar in den Dumps).
- Windows scheint Pakete mit bis zu 26334 Bytes zu senden (wenn ich die Daten richtig gelesen habe! Bitte überprüfen.), Auch wenn die MTU dies nicht zulassen sollte, da sie auf dem NAS auf 1500 eingestellt ist, wäre die maximale Einstellung dort 9000 (Synology also) verwendet die Einstellung 1500 für ihre Tests).
- Der Versuch, macOS durch Hinzufügen
smb_neg=smb3_onlyder Datei /etc/nsmb.conf zur Verwendung von SMB3 zu zwingen, funktionierte nicht oder führte zumindest nicht zu schnelleren Übertragungen. - Das Ausführen
rsync --sockopts=TCP_NODELAYmit verschiedenen Kombinationen von TCP-Einstellungen für verzögerte Bestätigung (0 bis 3) hatte keine Auswirkung (Hinweis: Ich habe den tcpdump mit der Standard-Bestätigungseinstellung 3 ausgeführt).
Ich habe 4 Speicherauszüge als CSV-Dateien erstellt, 2 beim Kopieren von 512 MB (Testdatei) und 2 beim Kopieren von 1024 MB (Testdatei). Sie können die Wireshark-Exporte hier herunterladen (25,2 MB). Sie sind platzsparend mit einem Reißverschluss versehen und werden selbsterklärend benannt.
Update 3 - smbutil Ausgabe
Ausgabe von smbutil statshares -awie von harrymc in den Kommentaren angefordert .
==================================================================================================
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
--------------------------------------------------------------------------------------------------
Beachten Sie Folgendes: Ich bin sicher SIGNING_SUPPORTED, truedass die Einstellung in der Konfiguration nicht funktioniert , wenn Sie hier sind. Aber nur das es vom NAS unterstützt wird. Ich habe dreifach überprüft, ob das Ändern der signing_requiredEinstellung in meiner Konfiguration Auswirkungen auf die Schreibgeschwindigkeit hat (~ 20 MB / s bei aktivierter Einstellung, ~ 60 MB / s bei deaktivierter Einstellung).
Update 4 - Samba Wars: Eine neue Hoffnung
Es fühlt sich etwas peinlich an, aber das Hauptproblem scheint auch hier die Messung zu sein.
Stellt sich heraus, rsync --progress -akostet etwa 30 MB / s Schreibgeschwindigkeit. Schreiben mit dddirektem Zugriff auf die SMB-Freigabe und Verwenden time cp /local/test.file /NAS/test.filesind mit ca. 85-90 MB / s schneller und der anscheinend schnellste Weg zum Kopieren ist der macOS Finder mit ca. 100 MB / s (was auch die am schwierigsten zu messende Methode ist, da es keine gibt) Zeit- oder Geschwindigkeitsanzeige - wer braucht das, oder? Wir haben es gemessen, indem wir zuerst eine 1-GB-Datei und dann eine 10-GB-Datei mit einer Stoppuhr kopiert haben.
Was wir seit dem letzten Update dieser Frage versucht haben.
- Kopieren Sie vom Mac-Client zum Mac-Client. Beide haben SSDs (MacPro schreibt mit 250 MB / s auf eigene Disc, MacBook Pro mit 300 MB / s). Ergebnis: magere 65 MB / s beim
ddSchreiben von MacBook Pro auf MacPro (rsync25 MB / s). Die 25 MB / s zu sehen war der Moment, als wir anfingen, rsync in Frage zu stellen. Trotzdem sind 65 MB / s extrem langsam. Die SMB-Implementierung unter macOS scheint also ... fragwürdig. - Versuchte verschiedene Ack-Einstellungen mit dd und cp - kein Glück.
- Schließlich haben wir eine Möglichkeit gefunden, alle verfügbaren nsmb.conf-Optionen aufzulisten. Es ist einfach
man nsmb.conf. Achtung die Online-Version ist veraltet!
Also haben wir noch ein paar Einstellungen ausprobiert, darunter:
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
Hinweis: smb_neg=smb3_onlyist - wie ich bereits erwartet habe - keine gültige Einstellung. protocol_vers_map=4sollte das gültige Äquivalent sein.
Wie auch immer, keine dieser Einstellungen hat einen Unterschied für uns gemacht.
Neue Fragen auf einen Blick
Warum ist rsync so teuer, um eine (1!) Datei zu kopieren? Hier gibt es nicht viel zu synchronisieren / vergleichen, oder? Der tcpdump zeigt auch keinen möglichen Overhead an.
Warum sind
ddundcplangsamer als der MacOS Finder beim Übertragen auf eine SMB-Freigabe? Beim Kopieren mit Finder scheint die TCP-Kommunikation deutlich weniger Bestätigungen zu enthalten. (Nochmals: Die Einstellung ack hat zBdelayed_ack=1für uns keinen Unterschied gemacht.)Warum scheint Windows die MTU zu ignorieren und sendet deutlich größere und damit weniger TCP-Pakete, was im Vergleich zu allem, was über macOS möglich ist, die beste Leistung erbringt.
So sehen die Pakete von macOS aus (ständig 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"
Und das kommt von Windows (bis zu 26334, in der Größe unterschiedlich)
"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"
Sie können hier die vollständige CSV- Datei herunterladen (25,2 MB). Die Dateinamen erläutern, was kopiert wurde (Betriebssystem, Übertragungsmethode und Dateigröße).
quelle
Antworten:
Hier Zitat "Peter van Hooft". Obwohl ich nicht sicher bin, ob ich die Basis für welche / welche Linux-Distribution teste. und Version von Rsync auch. Allerdings: 1. Er überlegt, ob wir versuchen sollen, --sparse flag zu verwenden, um die Leistung zu steigern. 2. Er hat das NFS-Protokoll getestet, ist jedoch auf dasselbe Geschwindigkeitsproblem gestoßen. Daher liegt es möglicherweise nicht am Protokoll (SMB2 / 3, AFP usw.).
LWN.net hat die Schlussfolgerung, dass Leistungsprobleme für den Kernel relevant sein können, selbst wenn der Artikel aus dem Jahr 2010 stammt. Auf NAS oder MacOS können wir nichts ändern. Dieser Artikel gibt uns jedoch einen Hinweis darauf, dass das Kernelproblem durch die Berechnung der Prüfsumme (meine Vermutung) verursacht werden kann.
Auch Zitat Kommentare hat dies:
Update 1 : Mein Fehler, diese Beschreibung ist für --checksum. check it here: [Verbesserte Beschreibung der Option --checksum.] PS, ich habe nicht genug Reputation, um mehr als 2 Links zu posten.
Aber ich kann dieselbe Beschreibung nicht auf der rsync-Manpage finden, daher schätze ich, dass jemand unter Fettdruck darüber spricht:
Vergleichen Sie daher mit cp / tar / cat. Wenn Sie mit rsync mehrere kleine oder große Dateien kopieren, kann dies zu Leistungsproblemen führen. ABER da ich den Quellcode von rsync nicht lesen kann, kann ich nicht bestätigen, dass dies der ultimative Grund ist.
meine idee ist immer wieder zu überprüfen:
Flaggen
Zum Schluss würde ich empfehlen, diesen Zusatzbeitrag zu lesen, um mehr darüber zu erfahren.
"So übertragen Sie große Datenmengen über das Netzwerk" moo.nac.uci.edu/~hjm/HOWTO_move_data.html
quelle
Rsync / ssh verschlüsselt die Verbindung smb nicht, wenn ich mich richtig erinnere. Wenn es sich nur um eine Datei handelt, kann möglicherweise ein System diese Datei lesen und das andere nicht. Beachten Sie auch, dass Sie "Giganten" / "Jumbo-Frames" -Pakete aktivieren müssen, um eine MTU über 1514 zu haben. Das zweite, was zu beachten ist, ist, dass "Riesen" / "Jumbo Frames" an beiden Enden und an ALLEN ZWISCHEN aktiviert sein müssen.
1514 sind die normalen Ethernet-Frames. 6k-9k-Frames werden je nach Betriebssystem / Anwendung als Riesen oder "Jumbo-Frames" bezeichnet
Ich durchschnittlich 80 MB / s zwischen meinem NAS (ein PC mit VMs, einer der VMs ist der NAS) und meiner Station (ein PC) mit SFTP (unter Verwendung von SSHFS) [Riesen nicht aktiviert] und das Gerät dazwischen ist eine Microtik 2011 (wird ausgeführt) nur Tru-Switch-Chip)
Denken Sie daran, dass die MTU zwischen zwei Punkten ausgehandelt wird und dass auf einem Pfad möglicherweise mehrere MTUs mit unterschiedlicher Kapazität vorhanden sind und dass die MTU die niedrigste verfügbare ist.
Bearbeiten: SMB ist nicht sehr effizient für Dateiübertragungen.
quelle