Dlaczego widzę tak niską przepustowość transferu SMB?

Ok, w tej historii jest coś więcej niż sugeruje tytuł.

Tło i środowisko : kopiuję kilka TB ze starszego serwera Ubuntu na nowszy serwer Windows 2012 przez SMB. (Technicznie rzecz biorąc, jest to sprzęt towarowy, ale tutaj są serwery.) Wszyscy są w gigabitowej sieci LAN, a starsze pudełko Ubuntu ma połączony interfejs. Wierzę, że serwer Ubuntu ma dwie karty Ethernet Ethernet Rosewill PCI-e 1x, a serwer Windows ma jedną rozsądną kartę PCI Intel Ethernet.

Komputer docelowy (serwer Windows) uruchamia pulę pamięci z parzystością na dyskach 4x 2 TB. Działa z nowym ReFS Microsoftu. Komputer źródłowy (serwer Ubuntu) obsługuje programowe dublowanie RAID. Działa dobrze, stary EXT4.

Dwa serwery pracują przez pojedynczy przełącznik gigabitowy. Eksperymentowałem z zerwaniem wiązania na komputerze źródłowym (Ubuntu) bez żadnej poprawy.

Problem : Nie mam problemów z przesyłaniem z rozsądną prędkością z innych komputerów na serwer Windows. Inne komputery mogą utrzymywać 50-80 MB / s bez większych trudności, ale transfer z tego serwera Ubuntu osiąga maksimum 20 MB / s. 4 + TB przy prędkości 20 MB / s zajmuje dużo czasu (około 2,3 dnia) i zastanawiam się, co mogę zrobić, aby dowiedzieć się, gdzie jest wąskie gardło.

Objawy : Procesor na obu komputerach jest dość minimalny i na pewno nie jest zbyt zajęty. Dyski twarde na obu komputerach są aktywne, ale nie są zalane, a oczekiwanie na procesor wynosi prawie 0% na co najmniej serwerze Ubuntu.

Zrobiłem śledzenie Wireshark przez 35 sekund (przypuszczalnie wystarczająco długo, aby upewnić się, że wszystkie ACK są dla nowych pakietów) i zauważyłem, że było kilka rzeczy, których się nie spodziewałem. (1) Nie było żadnych sum kontrolnych dla ACK (i NIEKTÓRYCH pakietów SMB) z Windows do Ubuntu. Wireshark twierdzi jednak, że może to być spowodowane „odciążeniem sumy kontrolnej IP”. Ok, mam tam całkiem niezłą kartę. Przypuszczam, że możliwe jest, że karta sieciowa może wykonać obliczenia sumy kontrolnej. W porządku. Przechodzę ... (2) „TCP ACKed niewidzialny segment”. Z tym mam problem. Numer ACK mieści się w akceptowalnym zakresie od tego, co mogę powiedzieć, i często są ogromne bloki tych wiadomości. Być może Wireshark jest po prostu zbyt wolny?

Podsumowanie : Prędkość transferu jest do bani (20 MB / s przez Gigabit Ethernet) i nie wiem dlaczego. Wireshark twierdzi, że Windows sprawdza, co nigdy nie zostało wysłane przez Ubuntu.

Domysły : Moje początkowe przypuszczenie jest takie, że tańsze karty Rosewill zostają zalane. Moim drugim przypuszczeniem jest to, że oprogramowanie podobne do RAID na jednym lub drugim końcu jest zalewane rzeczami do zrobienia.

Luka w wydajności pokrywa się z powszechnym doświadczeniem, gdy Samba (nie jestem pewien, czy nadal jest to domyślna; przez długi czas) jest skonfigurowana z domyślnym rozmiarem bufora gniazda odczytu i zapisu wynoszącym 1024 bajty.

Często widywałem to na maszynach z systemem Linux i Mac. Mam nadzieję, że nadal nie jest tak.

W pliku konfiguracyjnym samby znajduje się argument opcji gniazda, w którym można ustawić rozmiar bufora gniazda odczytu i zapisu. Sugerujemy ustawienie obu na 8192 bajtów (8 KiB). 4 lub 8 KB jest często podobne, ale nie testowałem tego na łączu gigabitowym.

Nie należy również oczekiwać, że jedno połączenie TCP skorzysta z połączonego łącza, ruch prawie zawsze będzie przechodził przez jedno z łączy; w przeciwnym razie skończy się z wieloma pakietami poza kolejnością; więc oczekuj tylko korzyści z równoważenia obciążenia podczas obsługi wielu klientów. Nawet wtedy powinieneś sprawdzić różne tryby łączenia i wiedzieć, że dla co najmniej "trybu 4" (IEEE 802.3ad) istnieją zasadniczo dwa tryby mieszania transmisji, które określają, który interfejs slave wysłać. Występuje skrót mieszania warstwy 2 (domyślnie) i mieszanie warstwy 3. Jeśli większość danych jest wysyłana przez bramę, skrót warstwy 2 nie będzie się dobrze dystrybuował, ponieważ adres MAC bramy będzie taki sam. Zamiast tego rozważ użycie warstwy 3.

Kiedyś miałem dwie karty Ethernet w jednym komputerze Ubuntu i z jakiegoś powodu nie działało to poprawnie - obie rywalizowały o te same pakiety, jak się wydawało, więc czasami dostaję odpowiedź, czasem nie, w zależności od tego, czy inna karta sieciowa złapie zapakowany. To było dziwne. Musiałem jakoś źle go skonfigurować, ale pomyślałem, że to po prostu zadziała. Karty miały oczywiście unikalne adresy IP.

W każdym razie byłoby łatwo wypróbować go z JEDNYM kartem Ethernet w urządzeniu podłączonym do sieci, aby to wykluczyć.