Na polu optymalizacji stosu sieciowego i usług sieciowych pod kątem sieci gigabitowych i wysokich transferów doświadczenia wybitnego nie mam… ale kilka ciekawych pomysłów rozważyć warto.

Przemyślenia zebrane z Sieci zostały sprawdzone na konfiguracji testowej w sieci Gigabit – przesyłanie dużego pliku po CIFS:

Serwer:

• Linux 2.6.22, Samba 3.0.27a
• Celek 2 GHz, 1,5 GB RAM
• Realtek 8169 Gigabit (driver: r8169, NAPI)

Klient:

• Linux 2.6.22, Samba 3.0.27a
• Celek 3 GHz, 0,5 GB RAM
• Marvell/Yukon Gigabit (driver: skge, NAPI)

Sieć dosyć rozległa, okablowanie głównie UTP-5 lub UTP-6. Dwa gigabitowe przełączniki Linksysa. RTT na poziomie 0.1 ms. Maksymalny transfer pomiędzy serwerem i klientem według iperf, to około 500 Mbit/s (62 MB/s).

Nie testowałem sterowników nieużywających NAPI, choć sprawdziłem test z klientem Windows XP, który dał wynik o 25% gorszy od linuksowej Samby.

Pierwsze testy na używanej konfiguracji pokazały transfer rzędu 31 MB/s. Uzyskane rezultaty końcowe to transfer od serwera do klienta na poziomie 43 MB/s (zysk: 33%). Nie został wykluczony udział dysku klienta – teoretycznie, aby test był w pełni miarodajny, dane z Sieci powinny lecieć na lokalny RAM-dysk. W przypadku serwera dane leciały z pamięci podręcznej stron, więc tam dysk nie miał znaczenia. Test był ukierunkowany na maksymalny transfer, więc nie badałem zachowania przy przesyłaniu dużej liczby małych plików.

Przede wszystkim jakby ktoś pogrzebał w Google po słowach “linux TCP tunning”, to wpierw by się natknął na modyfikacje parametrów stosu sieciowego – głównie wielkości “window” i buforów. Zwiększanie wielkości okna (domyślne wartości w poradnikach uznawane za zbyt niskie) nie zmieniły nic.

Największe znaczenie miały parametry buforów socketów w Sambie. Przy wielkości 8192 wszystko się zatykało do około 30 MB/s. Przy 16384 i 32768 skoczyło do około 42 MB/s. Wyłączenie algorytmu Nagle’a (TCP_NODELAY), które sugeruje “Official HOWTO“, zmniejszyło transfer do 40 MB/s, czyli teoretycznie słusznym wydaje się osąd zaprezentowany w “How to achieve Gigabit speeds with Linux“. W końcu konfiguracja Samby stanęła na:

socket options = SO_RCVBUF=32768 SO_SNDBUF=32768

Kolejne optymalizacje okazały się kosmetyką. Zwiększenie txqueuelen z domyślnego 1000 do 2000 czy nawet 10000 miało marginalny wpływ. Możliwe, że przy większej liczbie maszyn pobierających z serwera będzie to miało większe znaczenie. Podobnie net.core.netdev_max_backlog (domyślnie 1000) oraz wyłączenie SACK (Selective Acknowledgment, teoretycznie bardzo przydatne przy łączach gubiących pakiety). Niemniej po:

# ip link set eth2 txqueuelen 2000
# sysctl net.core.netdev_max_backlog=2000
# sysctl net.ipv4.tcp_dsack=0
# sysctl net.ipv4.tcp_sack=0
transfer skoczył o kolejne 1 MB/s, do 43 MB/s.

Nie przetestowałem czegoś, co może mieć tu ogromne znaczenie – Jumbo frames – z powodu potencjalnej ingerencji w infrastrukturę (przełączniki). Jeśli miałbym wysunąć wnioski, to może takie myśli by mi się nasunęły:

• używaj sterowników wspierających NAPI.
• nie wierz przestarzałym manualom (np. Samby) odnośnie tunningowania.
• jeśli masz nowy kernel, to masz zapewne domyślne ustawienia stosu sieciowego poprawne – również pod kątem wydajności – nie optymalizuj .