Tl; dr - Nie możemy znaleźć przyczyny ograniczonej prędkości zapisu 60 MB / s na nasz NAS przez SMB i AFP z dwóch różnych klientów Mac. Dla porównania: stary laptop z systemem Windows 7 w tej samej sieci zapisuje stałe 100 MB / s.
Jeśli czytasz to pytanie po raz pierwszy, przejdź do sekcji Aktualizacja 4 . rsync
jest głównym powodem niskiej prędkości, mimo że nie rozumiemy, dlaczego (dla jednego pliku!).
Oryginalne pytanie: Znajdź wąskie gardło szybkości SMB3 / NAS w systemie Mac OS 10.11.5 i nowszych
Przetestowaliśmy za pośrednictwem rsync --progress -a /localpath/test.file /nas/test.file
systemu macOS i informacji o kopii systemu Windows.
NAS to DS713 + z bieżącym DSM 6.0.2 (testowany również z 5.x), z dwoma HGST Deskstar NAS SATA 4TB (HDN724040ALE640) w RAID1 z tylko gigabitowymi komponentami ethernetowymi i nowymi kablami ethernetowymi (przynajmniej Cat5e).
Klienci komputerów Mac najpierw osiągnęli tylko 20 MB / s. Ale zastosowanie signing_required=no
poprawki (opisanej tutaj ) zwiększyło prędkość zapisu do 60 MB / s za pośrednictwem SMB2 i SMB3. AFP zapewnia również około 60 MB / s. Wynik waha się około 5 MB / s w zależności od protokołu i klienta (Mac).
Co już wypróbowaliśmy:
Sieć
- Testowana wydajność sieci przez iperf3. Wynik: 926 Mbit / s. Wygląda dobrze.
- Wypróbowany interfejs sieciowy Dual Link / Bonded. Brak zmiany.
- Zwiększono MTU do 6000 i 9000. Bez zmian.
- Sprawdziłem wszystkie kable. Wszystko w porządku przynajmniej Cat5e, w dobrym stanie.
Dyski
- Sprawdzone SMART Wygląda zdrowo.
- Przetestowane prędkość zapisu bezpośrednio na dysk ze
dd if=/dev/zero of=write.test bs=256M count=4
z różnymibs
icount
ustawieniami (128/8, 512M / 2, 1024/1). Wynik: około 120 MB / s (w zależności od rozmiaru / liczby bloków)
SMB / AFP
Benchmarked SMB2, SMB3 i AFP względem siebie. O równej.
Zobacz aktualizację poniżej: Użyto niewłaściwej metody, aby wykluczyć implementację SMB macOS. SMB w systemie Windows jest szybszy, przyczyną mogą być nowe ustawienia SMB dostarczane z MacOS 10.11 i 10.12.- Próbowałem dostosować ustawienia SMB, w tym opcje gniazd (postępując zgodnie z tą instrukcją )
- Próbowałem innej wersji ustawień opóźnionego potwierdzenia i
rsync --sockopts=TCP_NODELAY
(komentarze)
Brak znaczącej zmiany prędkości zapisu. Dokładnie sprawdziliśmy, czy konfiguracja została naprawdę załadowana i edytowaliśmy odpowiedni plik smb.conf .
System
- Obserwowane obciążenie procesora i pamięci RAM. Nic się nie rozwija. Procesor około 20%, pamięć RAM około 25% podczas transferu.
- Testowałem ten sam NAS z DSM 5.xx w konfiguracji niemalże od razu po wyjęciu z pudełka. Nie zainstalowano dodatkowego oprogramowania. Uwaga: mamy dwa z nich w różnych lokalizacjach. Są zsynchronizowane przez CloudSync firmy Synology. Ten sam wynik.
- Zdezaktywowano wszystko, co niepotrzebne, co mogło pociągnąć za sobą zasoby systemowe.
Uważamy, że jest to raczej domyślna konfiguracja, bez wymyślnych adaptacji, klientów lub komponentów sieciowych. Według wskaźników opublikowanych przez Synology NAS powinien pracować z szybkością od 40 MB / s do 75 MB / s szybciej. Ale po prostu nie możemy znaleźć wąskiego gardła.
Klienci / NAS
Klientami Mac są MacPro 5,1 (standardowa przewodowa karta sieciowa, działająca w wersji 10.12.3 (16D32)) i MacBookPro10,1 (karta sieciowa Thunderbolt, działająca w wersji 10.11.6), tylko około 2 m kabla od NAS, działającego na tym samym przełącznik gigabitowy jako laptop Windows w teście.
Mamy dwa z tych NAS w różnych lokalizacjach, a wyniki są identyczne. Sekundy NAS jest mniej więcej domyślnym ustawieniem fabrycznym (nawet nie jest zainstalowane oprogramowanie innej firmy). Tylko dwa dyski sformatowane w RAID1, EXT4 synchronizują się z innym serwerem NAS za pośrednictwem Synology CloudSync. Zaszliśmy tak daleko, jak bezpośrednie połączenie z NAS bez przełącznika, ten sam wynik.
Ważna aktualizacja
Metoda zastosowana do wykluczenia implementacji SMB macOS / OS X była nieprawidłowa. Przetestowałem go za pomocą maszyny wirtualnej, zakładając, że używałby własnej wersji SMB, ale oczywiście ruch jest przekazywany do macOS, przez jego wersję SMB.
Korzystając z laptopa z systemem Windows, byłem w stanie osiągnąć średnio 100 MB / s. Wskazanie implementacji / aktualizacji SMB nadchodzących z 10.11 i 10.12 może spowodować niską wydajność. Nawet jeśli signing_required
jest ustawiony na no
.
Byłoby wspaniale, gdyby ktoś mógł wskazać dalsze ustawienia, które mogły ulec zmianie wraz z aktualizacjami i mogą wpłynąć na wydajność.
Aktualizacja 2 - nowe informacje
AndrewHenle wskazał w komentarzach, że powinienem szczegółowo zbadać ruch za pomocą Wireshark, aby uzyskać więcej informacji.
W związku z tym uruchomiłem sudo tcpdump -i eth0 -s 65535 -w tcpdump.dump
na serwerze NAS, jednocześnie przesyłając dwa pliki testowe, jeden z 512 MB, a drugi z 1 GB. I sprawdziłem zrzut za pomocą Wiresharka.
Co znalazłem:
- Wydaje się, że zarówno OS X, jak i Windows używają SMB2, chociaż SMB3 jest włączony na NAS (przynajmniej zgodnie z Wireshark).
- OS X wydaje się trzymać z MTU . Pakiety mają 1514 bajtów, co prowadzi do znacznie większego obciążenia sieci i wysłanych pakietów (widoczne na zrzutach).
- Windows wydaje się wysyłać pakiety do 26334 bajtów (jeśli poprawnie odczytam dane! Proszę zweryfikować). Nawet jeśli MTU nie powinno na to pozwolić, ponieważ jest ustawiony na 1500 na NAS, maksymalne ustawienie wyniesie tam 9000 (Synology również używa ustawienia 1500 w swoich testach).
- Próba zmuszenia macOS do używania SMB3 przez dodanie
smb_neg=smb3_only
do pliku /etc/nsmb.conf nie działała lub przynajmniej nie prowadziła do szybszych transferów. - Praca
rsync --sockopts=TCP_NODELAY
z różnymi kombinacjami ustawień opóźnionego potwierdzenia TCP (od 0 do 3) nie przyniosła żadnego efektu (Uwaga: Uruchomiłem tcpdump z domyślnym ustawieniem potwierdzenia na 3).
Utworzyłem 4 zrzuty jako pliki .csv, 2 podczas kopiowania 512 MB (plik test-2.) i 2 podczas kopiowania 1024 MB (plik test.file). Możesz pobrać eksport Wireshark tutaj (25,2 MB). Są spakowane w celu zaoszczędzenia miejsca i nazwane w sposób zrozumiały.
Aktualizacja 3 - wyjście smbutil
Wyjście smbutil statshares -a
zgodnie z żądaniem Harrymca w komentarzach.
==================================================================================================
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
--------------------------------------------------------------------------------------------------
Uwaga na ten temat: jestem pewien SIGNING_SUPPORTED
, że obecność true
tutaj nie oznacza, że ustawienie w konfiguracji nie działa. Ale tylko to jest obsługiwane przez NAS. Potrójnie sprawdziłem, czy zmiana signing_required
ustawienia w mojej konfiguracji ma wpływ na szybkość zapisu (~ 20 MB / s po włączeniu, ~ 60 MB / s przy wyłączeniu).
Aktualizacja 4 - Samba Wars: Nowa nadzieja
To trochę zawstydzające, ale głównym problemem tutaj - znowu - wydaje się być pomiar.
Okazuje się, że rsync --progress -a
kosztuje około 30 MB / s prędkości zapisu. Pisanie dd
bezpośrednio z udziałem SMB i korzystanie z nich time cp /local/test.file /NAS/test.file
jest szybsze z prędkością około 85-90 MB / s, a najwyraźniej najszybszym sposobem kopiowania jest wyszukiwarka macOS z prędkością około 100 MB / s (co jest również najtrudniejszą metodą do zmierzenia, ponieważ nie ma wskaźnik czasu lub prędkości - kto tego potrzebuje, prawda? o_O). Zmierzyliśmy go, najpierw kopiując plik 1 GB, a następnie plik 10 GB, używając stopera.
Co próbowaliśmy od ostatniej aktualizacji tego pytania.
- Skopiuj z klienta Mac na klienta Mac. Oba mają dyski SSD (MacPro zapisuje z szybkością 250 MB / s na własny dysk, MacBook Pro z 300 MB / s). Wynik: skromny 65 MB / s dzięki
dd
pisaniu z MacBooka Pro na MacPro (rsync
25 MB / s). Widok 25 MB / s był momentem, kiedy zaczęliśmy przesłuchiwać rsync. Nadal 65 MB / s są bardzo wolne. Implementacja SMB na macOS wydaje się… cóż, wątpliwa. - Próbowałem różnych ustawień potwierdzenia z dd i cp - bez powodzenia.
- Wreszcie znaleźliśmy sposób, aby wyświetlić listę wszystkich dostępnych opcji nsmb.conf. To jest proste
man nsmb.conf
. Uwaga wersja online jest nieaktualna!
Wypróbowaliśmy więc kilka innych ustawień, w tym:
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
Uwaga: smb_neg=smb3_only
- jak już się spodziewałem - nie jest prawidłowym ustawieniem. protocol_vers_map=4
powinien być prawidłowym odpowiednikiem.
W każdym razie żadne z tych ustawień nie miało dla nas znaczenia.
Nowe pytania w skrócie
Dlaczego rsync jest tak drogim sposobem na skopiowanie jednego (1!) Pliku. Nie ma tu wiele do synchronizacji / porównania, prawda? Tcpdump również nie wskazuje możliwego obciążenia.
Dlaczego
dd
icp
wolniej niż wyszukiwarka macOS podczas przesyłania do udziału SMB? Wydaje się, że podczas kopiowania za pomocą Findera potwierdzeń w komunikacji TCP jest znacznie mniej. (Ponownie: ustawienie potwierdzenia np. Niedelayed_ack=1
miało dla nas znaczenia.)Dlaczego Windows wydaje się ignorować MTU, wysyłając znacznie większe, a tym samym mniej pakietów TCP, co daje najlepszą wydajność w porównaniu do wszystkiego, co możliwe za pośrednictwem macOS.
Tak wyglądają pakiety z macOS (ciągle 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"
A to pochodzi z systemu Windows (do 26334, różniących się wielkością)
"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"
Możesz pobrać pełny plik .csv tutaj (25,2 MB), nazwy plików wyjaśniają, co zostało skopiowane (system operacyjny, metoda przesyłania i rozmiar pliku).