Podczas wykonywania małych zapisów próbowałem rozwiązać problem z wydajnością udziału SMB / CIFS.
Najpierw opiszę moją obecną konfigurację sieci:
serwer
- Synology DS215j (z włączoną obsługą SMB3)
Klienci (ten sam komputer, przewodowy Gig-E z podwójnym uruchomieniem)
- Ubuntu 14.04.5 LTS, Trusty Tahr
- Windows 8.1
smb.conf
[global]
printcap name=cups
winbind enum groups=yes
include=/var/tmp/nginx/smb.netbios.aliases.conf
socket options=TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=65536 SO_SNDBUF=65536
security=user
local master=no
realm=*
passdb backend=smbpasswd
printing=cups
max protocol=SMB3
winbind enum users=yes
load printers=yes
workgroup=WORKGROUP
Obecnie testuję małą wydajność zapisu za pomocą następującego programu napisanego w C ++ ( tutaj na GitHub ):
#include <iostream>
#include <fstream>
#include <sstream>
using namespace std;
int main(int argc, char* argv[])
{
ofstream outFile(argv[1]);
for(int i = 0; i < 1000000; i++)
{
outFile << "Line #" << i << endl;
}
outFile.flush();
outFile.close();
return 0;
}
Konfiguracja montowania w systemie Linux:
//192.168.1.10/nas-main on /mnt/nas-main type cifs (rw,noexec,nodev)
Czas działania programu w systemie Linux (szczytowa wydajność sieci przy ~ 100 Mb / s):
$ time ./nas-write-test /mnt/nas-main/home/will/test.txt
real 0m0.965s
user 0m0.148s
sys 0m0.672s
Migawka PCAP pokazująca fragmentowanie wielu linii w jednym pakiecie TCP:
Czas działania programu w systemie Windows mierzony za pomocą programu PowerShell:
> Measure-Command {start-process .\nas-write-test.exe -argumentlist "Z:\home\will\test-win.txt" -wait}
Days : 0
Hours : 0
Minutes : 9
Seconds : 29
Milliseconds : 316
Ticks : 5693166949
TotalDays : 0.00658931359837963
TotalHours : 0.158143526361111
TotalMinutes : 9.48861158166667
TotalSeconds : 569.3166949
TotalMilliseconds : 569316.6949
Migawka PCAP w systemie Windows z pojedynczą linią dla każdego żądania zapisu SMB:
Ten sam program zajmuje około 10 minut (~ 2,3 Mb / s) w systemie Windows. Oczywiście Windows PCAP pokazuje bardzo głośną rozmowę SMB o bardzo niskiej wydajności.
Czy są jakieś ustawienia w systemie Windows, które mogą poprawić wydajność małego zapisu? Wygląda na to, że patrząc na przechwytywanie pakietów, Windows nie buforuje poprawnie zapisów i natychmiast wysyła dane po jednej linii na raz. Natomiast w systemie Linux dane są mocno buforowane, a zatem mają znacznie lepszą wydajność. Daj mi znać, czy pliki PCAP będą pomocne, a ja mogę znaleźć sposób na ich przesłanie.
Aktualizacja 27.10.16:
Jak wspomniano w @sehafoc, zmniejszyłem max protocolustawienie serwerów Samba do SMB1, wykonując następujące czynności:
max protocol=NT1
Powyższe ustawienie spowodowało dokładnie takie samo zachowanie.
Usunąłem również zmienną Samby, tworząc udział na innym komputerze z systemem Windows 10, a także wykazuje to samo zachowanie, co serwer Samba, więc zaczynam wierzyć, że jest to błąd buforowania zapisu ogólnie dla klientów Windows.
Aktualizacja: 10/06/17:
Przechwytywanie pełnego pakietu Linux (14 MB)
Przechwytywanie pełnego pakietu Windows (375 MB)
Aktualizacja: 10/12/17:
Skonfigurowałem również udział NFS, a system Windows również pisze bez buforowania. Jest to zdecydowanie podstawowy problem klienta Windows, o ile wiem, co jest zdecydowanie niefortunne: - /
Każda pomoc będzie mile widziana!
Nie mam wystarczającej reputacji, aby zostawić komentarz (co moim zdaniem byłoby lepiej, biorąc pod uwagę poziom weryfikacji tej odpowiedzi).
Zauważam, że jedną dużą różnicą w śledzeniu na poziomie Linux vs. Windows jest to, że używasz SMB1 w systemie Linux i SMB2 w systemie Windows. Być może mechanizm blokowania partii działa lepiej w sambie SMB1 niż w ekskluzywnej implementacji dzierżawy SMB2. W obu przypadkach powinny one zezwalać na buforowanie po stronie klienta.
1) Być może spróbuj ustawić niższy maksymalny poziom protokołu w Sambie, aby wypróbować system Windows za pomocą SMB1 2) Sprawdź, czy wyłączane są wyłączne blokady lub dzierżawy
Mam nadzieję że to pomoże :)
źródło
Na wydajność zdalnych operacji na plikach, takich jak odczyt / zapis przy użyciu protokołu SMB, może mieć wpływ rozmiar buforów przydzielanych przez serwery i klientów. Rozmiar bufora określa liczbę podróży w obie strony potrzebnych do wysłania określonej ilości danych. Za każdym razem, gdy żądania i odpowiedzi są wysyłane między klientem a serwerem, ilość czasu jest równa co najmniej opóźnieniu między obiema stronami, co może być bardzo znaczące w przypadku sieci rozległej (WAN).
Bufor SMB - MaxBufferSize można skonfigurować za pomocą następującego ustawienia rejestru:
Typ danych:
REG_DWORDZakres: od 1024 do 65535 (wybierz wartość zgodnie z wymaganiami powyżej 5000)
ALE SMB SIGNING wpływa na maksymalny dozwolony rozmiar bufora. Dlatego też musimy wyłączyć podpisywanie SMB, aby osiągnąć nasz cel. Należy utworzyć następujący rejestr zarówno po stronie serwera, jak i, jeśli to możliwe, również po stronie klienta.
Nazwa wartości:
EnableSecuritySignatureTyp danych:
REG_DWORDDane: 0 (wyłącz), 1 (włącz)
źródło
Ciekawe zjawisko. Oto, co bym spróbował - nie mam pojęcia, czy to naprawdę pomaga. Gdyby to była moja maszyna, intensywnie obserwowałbym perfcounterów SMB. Jednym z nich będzie wykazać przyczynę.
Więcej rzeczy do wypróbowania
Dodaj więcej wątków roboczych
W przypadku, gdy SMB_RDR wykryje jedno żądanie We / Wy zapisu na linię (co nie powinno się tu zdarzyć), może pomóc dodanie niektórych wątków do silnika wykonawczego.
Ustaw „AdditionalCriticalWorkerThreads” na 2, a następnie na 4.
Wartość domyślna to 0, co oznacza, że nie są dodawane żadne dodatkowe krytyczne wątki robocze jądra. Co zwykle jest w porządku. Ta wartość wpływa na liczbę wątków używanych przez pamięć podręczną systemu plików do żądania odczytu z wyprzedzeniem i zapisu. Zwiększenie tej wartości może pozwolić na kolejkowanie we / wy w podsystemie pamięci masowej (co jest dobre, gdy chcesz pisać wiersz po wierszu), ale jest to droższe procesor.
Dodaj więcej długości kolejki
Zwiększenie wartości „AdditionalCriticalWorkerThreads” zwiększa liczbę wątków, których serwer plików może użyć do obsługi współbieżnych żądań.
Wartość domyślna to 20. Wskazanie, że wartość może wymagać zwiększenia, to jeśli kolejki robocze SMB2 stają się bardzo duże (perfcounter „Serwerowe kolejki robocze \ Długość kolejki \ SMB2 *”. Powinien wynosić <100).
źródło