Dlaczego istnieje różnica prędkości zapisu między dd, cp, rsync i macOS Finder na dysku SMB3?

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 . rsyncjest 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.filesystemu 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=nopoprawki (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ć

1. Testowana wydajność sieci przez iperf3. Wynik: 926 Mbit / s. Wygląda dobrze.
2. Wypróbowany interfejs sieciowy Dual Link / Bonded. Brak zmiany.
3. Zwiększono MTU do 6000 i 9000. Bez zmian.
4. Sprawdziłem wszystkie kable. Wszystko w porządku przynajmniej Cat5e, w dobrym stanie.

Dyski

1. Sprawdzone SMART Wygląda zdrowo.
2. Przetestowane prędkość zapisu bezpośrednio na dysk ze dd if=/dev/zero of=write.test bs=256M count=4z różnymi bsi countustawieniami (128/8, 512M / 2, 1024/1). Wynik: około 120 MB / s (w zależności od rozmiaru / liczby bloków)

SMB / AFP

1. 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.
2. Próbowałem dostosować ustawienia SMB, w tym opcje gniazd (postępując zgodnie z tą instrukcją )
3. 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

1. Obserwowane obciążenie procesora i pamięci RAM. Nic się nie rozwija. Procesor około 20%, pamięć RAM około 25% podczas transferu.
2. 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.
3. 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_requiredjest 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.dumpna 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:

1. Wydaje się, że zarówno OS X, jak i Windows używają SMB2, chociaż SMB3 jest włączony na NAS (przynajmniej zgodnie z Wireshark).
2. 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).
3. 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).
4. Próba zmuszenia macOS do używania SMB3 przez dodanie smb_neg=smb3_onlydo pliku /etc/nsmb.conf nie działała lub przynajmniej nie prowadziła do szybszych transferów.
5. Praca rsync --sockopts=TCP_NODELAYz 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 -azgodnie 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ść truetutaj nie oznacza, że ​​ustawienie w konfiguracji nie działa. Ale tylko to jest obsługiwane przez NAS. Potrójnie sprawdziłem, czy zmiana signing_requiredustawienia 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 -akosztuje około 30 MB / s prędkości zapisu. Pisanie ddbezpośrednio z udziałem SMB i korzystanie z nich time cp /local/test.file /NAS/test.filejest 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.

1. 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 ddpisaniu z MacBooka Pro na MacPro ( rsync25 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.
2. Próbowałem różnych ustawień potwierdzenia z dd i cp - bez powodzenia.
3. 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=4powinien być prawidłowym odpowiednikiem.

W każdym razie żadne z tych ustawień nie miało dla nas znaczenia.

Nowe pytania w skrócie

1. 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.

2. Dlaczego ddi cpwolniej 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. Nie delayed_ack=1miało dla nas znaczenia.)

3. 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).

1. podobne pytanie, ale ma ciekawe odpowiedzi, być może możesz sprawdzić ten wątek, szczególnie w komentarzu 5: https://bugzilla.samba.org/show_bug.cgi?id=8512#c5

Tutaj cytuje „Peter van Hooft”. Chociaż nie jestem pewien, czy testowanie opiera się na tym, co / który linux dist. i wersja rsync też. Jednak: 1. namawia nas do wypróbowania - rzadka flaga, jeśli to możliwe, aby zwiększyć wydajność. 2. testował na protokole NFS, ale napotkał ten sam problem z prędkością, dlatego IT może nie jest przyczyną protokołu (SMB2 / 3, AFP itp.).

Używamy rsync do kopiowania danych z jednego serwera plików na inny przy użyciu podłączeń NFS3 za pośrednictwem łącza 10 Gb. Odkryliśmy, że zwiększenie rozmiarów buforów (jako szybki test) zwiększa wydajność. W przypadku użycia - rzadkie zwiększa to wydajność pięćdziesiąt razy, od 2 MB / s do 100 MB / s.

2. Oto kolejna interesująca kontrola wydajności rsync. https://lwn.net/Articles/400489/

LWN.net ma wnioski, że problem z wydajnością może dotyczyć jądra, nawet artykuł opublikowany w 2010 roku i nie możemy tego zmienić na NAS lub MacOS. Jednak ten artykuł daje nam do myślenia, że ​​problem z jądrem może być spowodowany obliczeniem sumy kontrolnej (moje zgadywanie).

Jedno jest pewne: powinienem zaktualizować jądro w moim systemie Mythtv. Ogólnie jądra 2.6.34 i 2.6.35-rc3 zapewniają lepszą wydajność niż stare jądro 2.6.27. Ale majstrując czy nie, rsync wciąż nie jest w stanie pobić prostego cp, który kopiuje z prędkością ponad 100 Mb / s. Rzeczywiście, rsync naprawdę potrzebuje dużej mocy procesora do prostych lokalnych kopii. Przy najwyższej częstotliwości procesor wymagał tylko 0,34 + 20,95 sekund czasu procesora, w porównaniu z rsync 70 + 55 sekund.

cytuj także komentarze:

Zauważ, że rsync zawsze sprawdza, czy każdy przesłany plik został poprawnie zrekonstruowany po stronie odbierającej, sprawdzając sumę kontrolną całego pliku, która jest generowana podczas przesyłania pliku

aktualizacja 1 : mój błąd, ten opis dotyczy --checksum. sprawdź tutaj: [Poprawiono opis opcji --checksum.] PS, nie mam wystarczającej reputacji, aby opublikować więcej niż 2 linki.

ale nie mogę znaleźć tego samego opisu na stronie podręcznika rsync, więc zgaduję, że ktoś mówi poniżej Pogrubienie:

Rsync znajduje pliki, które należy przesłać przy użyciu algorytmu „szybkiej kontroli” (domyślnie), który wyszukuje pliki, które zmieniły rozmiar lub czas ostatniej modyfikacji. Wszelkie zmiany innych zachowanych atrybutów (zgodnie z żądaniem opcji) są wprowadzane bezpośrednio do pliku docelowego, gdy szybkie sprawdzenie wskazuje, że dane pliku nie muszą być aktualizowane.

Dlatego w porównaniu do cp / tar / cat, jeśli użyjemy rsync do skopiowania kilku małych lub dużych plików, może to spowodować problemy z wydajnością. ALE ze względu na to, że nie jestem w stanie odczytać kodu źródłowego rsync, dlatego nie mogę potwierdzić, że jest to ostateczny powód.

moim pomysłem jest sprawdzanie:

1. Jakiej wersji rsync używa awenro do testowania? Czy możesz zaktualizować do najnowszej wersji?
2. zobaczmy, jakie dane wyjściowe należy zastosować --stats i -v z --debug = FLAGS

flagi

--stats Informuje to rsync, aby wypisał pełny zestaw statystyk dotyczących przesyłania plików, pozwalając ci powiedzieć, jak skuteczny jest algorytm rsync dla twoich danych.

--debug = FLAGI Ta opcja umożliwia dokładną kontrolę nad wynikiem debugowania, który chcesz zobaczyć. Po nazwie pojedynczej flagi może następować numer poziomu, przy czym 0 oznacza wyciszenie tego wyjścia, 1 oznacza domyślny poziom wyjścia, a wyższe liczby zwiększają wynik tej flagi (dla tych, które obsługują wyższe poziomy). Użyj --debug = help, aby zobaczyć wszystkie dostępne nazwy flag , ich wyniki i jakie nazwy flag są dodawane przy każdym wzroście poziomu szczegółowości.

na koniec polecam przeczytać ten dodatkowy post, aby uzyskać więcej wiedzy.
„Jak przesyłać duże ilości danych przez sieć” moo.nac.uci.edu/~hjm/HOWTO_move_data.html

Rsync / ssh szyfruje połączenie smb nie, jeśli dobrze pamiętam. Jeśli jest to tylko jeden plik, jeden system może odczytać ten plik, a drugi nie. Zauważ też, że aby MTU było wyższe niż 1514, musisz włączyć pakiety „gigantów” / „Jumbo Frames” fakt, że pakiety muszą być dalej zmniejszane, może to oznaczać, że istnieje „narzut” na „przepakowanie” pakietu. Drugą rzeczą do odnotowania jest to, że „gigantów” / „Jumbo Frames” muszą być włączone na obu końcach I WSZYSTKO MIĘDZY.

1514 to normalne ramki Ethernet. Ramki 6–9 tys. Nazywane są gigantami lub „ramkami Jumbo” w zależności od systemu operacyjnego / aplikacji

Średnio 80 MB / s między moim urządzeniem nos (komputer z maszynami wirtualnymi, jedną z maszyn wirtualnych jest NAS) i moją stacją (komputer) z sftp (używając sshfs) [gigantów nie włączono], a urządzeniem pomiędzy nimi jest microtik 2011 (będzie tylko układ przełącznika tru)

Pamiętaj, że MTU jest negocjowane między dwoma punktami i że na ścieżce możesz mieć kilka MTU o różnej pojemności i że MTU będzie najniższą dostępną.

edycja: SMB nie jest bardzo wydajny w przypadku przesyłania plików.