Trage performance tussen windows hosts over een 1Gbit MPLS

[Heloxide]

Sinds enkele dagen hebben we onze server opgesplitst over twee locaties. De locaties zijn onderling verbonden door een 1Gbit MPLS verbinding. Alle verbindingen lopen prima, en het synchroniseren van ons NAS (NetApp) verloopt met snelheden van +/- 600Mbps. Helaas geldt dat niet voor onze Windows servers. Met een RTT van 9 ms bereiken we een snelheid van ongeveer 47 Mbps tussen twee hosts.

Dmv registry aanpassingen in Windows zou ik de snelheid moeten kunnen opvoeren en een hogere doorvoersnelheid moeten kunnen halen. http://support.microsoft.com/kb/224829 beschrijft hoe dat te doen. Ik heb TcpWindowSize naar 536862720 gezet, en Tcp1323Opts op 1 (dit om de RTT uit te sluiten; met optie 3 haal ik dezelfde snelheid).
Echter, zelfs met deze aanpassingen haal ik geen hogere snelheden.
Als ik met Wireshark naar de 3way handshake kijk zie ik echter netjes Window Scale 13 staan. Volgens mij zou ik dan theoretisch 65535*2^13 =536Mbit moeten kunnen halen.

Heeft iemand enig idee wat ik over het hoofd zie?

[Question Mark]

Hoe test je die snelheid van 47 Mbps? Als je dit test door het kopieren van een file kan het natuurlijk een beperking van je disksysteem zijn.

Test (mocht je dit nog niet gedaan hebben) eens met Netio.

[Heloxide]

Testen zijn gedaan met zowel door copieeren van files (1GB+, niet gebruikte servers) en door NetCPS. De servers hebben overigens geen firewall ertussen. Ik zal Netio eens proberen.

[Heloxide]

Resultaten NetIO:
NETIO - Network Throughput Benchmark, Version 1.26
(C) 1997-2005 Kai Uwe Rommel

TCP connection established.
Packet size 1k bytes: 13013 KByte/s Tx, 6406 KByte/s Rx.
Packet size 2k bytes: 13394 KByte/s Tx, 12324 KByte/s Rx.
Packet size 4k bytes: 13376 KByte/s Tx, 13347 KByte/s Rx.
Packet size 8k bytes: 13375 KByte/s Tx, 13367 KByte/s Rx.
Packet size 16k bytes: 13372 KByte/s Tx, 13102 KByte/s Rx.
Packet size 32k bytes: 12740 KByte/s Tx, 9371 KByte/s Rx.
Done.

NETIO - Network Throughput Benchmark, Version 1.26
(C) 1997-2005 Kai Uwe Rommel

UDP connection established.
Packet size 1k bytes: 87125 KByte/s (9%) Tx, 64283 KByte/s (24%) Rx.
Packet size 2k bytes: 10189 KByte/s (0%) Tx, 39527 KByte/s (0%) Rx.
Packet size 4k bytes: 16432 KByte/s (0%) Tx, 48703 KByte/s (25%) Rx.
Packet size 8k bytes: 32854 KByte/s (0%) Tx, 3785 KByte/s (96%) Rx.
Packet size 16k bytes: 65682 KByte/s (0%) Tx, 429 KByte/s (99%) Rx.
Packet size 32k bytes: 65742 KByte/s (0%) Tx, 3211 KByte/s (97%) Rx.
Done.

Ik weet niet helemaal hoe ik de output moet interpreteren, maar volgens mij heb ik de meest optimale snelheid bij een packet size van 1k??

[Bl@ckbird]

Bij storage wordt data in grote blokken verzonden.
Windows File Sharing ( CIFS ) is erg chatty. ( Veel kleine packets. )
Om de paar verzonden TCP packets, wordt er een acknowledge packet verwacht.
In verband met de latency, zit je hier op te wachten. Dit verhaal heeft een grote impact op de maximale throughput die je kan halen. ( Ook al heb je een Gigabit lijn liggen. )

Zie:
http://www.babinszki.com/...t-and-TCP-Throughput.html
En kijk bij 9 ms latency.

CIFS is niet geschikt om over het WAN te doen. ( Veel kleine packets zijn op een LAN echter geen probleem. )
Een oplossing is WAN optimalisatie.

Zie ook:
\[VPN/SMB] Lage prestatie puur door latency?
GPRS/UMTS Slow link detectie & Offline Files
Nieuwe VDI oplossing: Solid ICE

[Heloxide]

Bedankt voor de reply. Eens kijken of er een oplossing is die niet al te duur wordt...

[Leon T]

Waarop slaan die percentages in de UDP test? Ik hoop toch dat dat geen packetloss is...

[serkoon]

Je hebt je TCP windows nu niet gescaled naar 536Mbit, maar 536Mbyte; nogal een verschil

Bij 9ms RTT heb je maar een window nodig van +/- 1.2MByte wil je de gigabit-link echt volledig met 1 stream kunnen benutten (heb header overhead en interframe gaps e.d. niet meegenomen).

Overigens ga ik mee met de voorgaande posters: je probleem zit waarschijnlijk niet in TCP maar in CIFS.

[Question Mark]

Dan zou TS nog een keer kunnen testen door meerdere sessie te starten en kijken waar de doorvoersnelheid van de gecombineerde sessies op uitkomt.

[Vicarious]

Of je stuurt je bestanden even over met FTP of TFTP?

[Heloxide]

Bestanden via FTP of TFTP zijn geen optie, aangezien ze door applicaties worden gelezen en geschrenen vanaf een share.

Op zich is fileshare performance niet een enorm groot probleem, we zouden zelfs alle shares op twee locaties kunnen zetten en de NetApp de synchronisatie laten doen. Wat wel een probleem kan gaan opleveren is SQL.

Heeft iemand enig idee hoe mssql data (TCP) zich verhoudt tot CIFS? Oftewel, is mssql wel in staat op queries met veel data efficient te versturen?

[Bl@ckbird]

Met wireshark ff sniffen. Je hebt dan een idee van de packet grootte.
Je kan een filter zetten op CIFS en SQL verkeer.

[Heloxide]

Bedankt voor de tips!
We gaan mbv een 3e partij een analyse laten uitvoeren om te kijken of een WAN appliance verbetering kan brengen.