Qual è la prestazione tipica di Windows File Sharing (SMB) su una rete Ethernet Gigabit?

Di recente ho impostato la condivisione di file Windows su una rete Ethernet Gigabit (non utilizzo frame jumbo) con un server Samba e un client Windows Vista. Ho fatto alcune copie dei file, ma il throughput massimo che sto vedendo è di 20 MB / s (megabyte, non megabit) che è circa il 15% del massimo teorico 125 MB / s per la rete. Il server ha un array RAID in grado di gestire circa 75 MB / s (il collo di bottiglia è il bus PCI) e il client può gestire circa 40 MB / s in una copia da disco a disco.

Dovrei aggiungere che al momento non c'era altro traffico sulla rete.

Capisco che non otterrò mai il massimo teorico, ma non pensavo che sarebbe stato così male.

Qual è la prestazione tipica di Windows File Sharing (SMB) su una rete Ethernet Gigabit?

Punti bonus: cosa posso sintonizzare (oltre ad usare i jumbo frame) per renderlo più veloce?

La qualità delle schede di rete, degli switch e dei cavi può avere tutti un effetto. Potrebbe valere la pena cercare recensioni delle schede NIC e degli switch che stai utilizzando per vedere se altre persone li segnalano come non funzionino troppo bene. Sono certo che le schede NIC integrate nella bacheca sono peggiori dei trasferimenti Gbit, anche se nella mia esperienza questo non sembra fare molta, se non nessuna, differenza nel mio ambiente.

Come punto di riferimento, ho appena installato un nuovo switch Gbit nel nostro ufficio (che sostituisce i vecchi switch 100Mbit) e grandi trasferimenti SMB vengono eseguiti a quasi (ma meno di) 30Mbyte / sec tra ogni combinazione di macchine che ho testato. Ho appena fatto un test rapido con netcat tra due macchine e ho ottenuto risultati simili, quindi non credo che SMB sia il collo di bottiglia. Le due macchine che ho appena testato hanno due interruttori tra loro che possono avere un effetto, ma immagino che l'effetto sia minimo dato quanto vicini i valori a un trasferimento SMB a una macchina sullo stesso interruttore.

La migliore velocità di trasferimento che ho visto su una rete Gbit è stata leggermente più veloce di 50 MByte / sec. Ciò avveniva durante il trasferimento di un'immagine di unità da una macchina a un file sull'altra (ai fini della conversione in un'unità virtuale VMWare. In quel caso le due macchine erano collegate tramite un cavo incrociato corto anziché tramite uno switch. una delle macchine in questione era una delle macchine che ho appena testato e da cui ho ricevuto ~ 29Mbyte / sec - il colpevole più probabile per il principale collo di bottiglia nel mio caso è probabilmente il cablaggio di 8 anni nell'edificio che potrebbe essere stato fatto a buon mercato! Un test rapido (e altrettanto non scientifico) sulla mia piccola rete domestica vede velocità di trasferimento più simili a 35Mbyte / sec copia un file da una condivisione Samba a una finestra di Windows e 25Mbyte / sec nella direzione opposta (I '

I frame jumbo faranno la differenza per i trasferimenti di massa, quindi ti suggerisco di provare se tutto il tuo kit li supporta correttamente.

Per farla breve: passare dalla mia esperienza aneddotica ai tuoi 20Mbyte / sec è un po 'lento, ma non così enormemente. Tutte le mie installazioni di Windows e Samba sono praticamente completamente non ottimizzate, quindi sospetto che il tuo hardware / cablaggio sia la differenza tra ciò che vedo e ciò che vedi.

modificare

Naturalmente, a cinque anni da questa risposta, l'hardware e il software sono passati. Vedo spesso oltre 90 trasferimenti MiB / sec su macchine con rete Gbit anche con kit economico. Il mio supporto domestico / backup / altro server sembra limitato a poco più di 60 per la massa per i trasferimenti, ma sembra che samba sia legato alla CPU su un singolo core dell'hardware della scatola.

Ahh ... questo è dove è importante per un ragazzo del server capire cosa c'è sotto il cofano. Dato che ha due anni, immagino che l'abbia già risolto. Tuttavia, per i posteri o per chiunque abbia un problema simile, probabilmente si è imbattuto in questo

(Dimensione finestra TCP * 8 bit / RTT in millisecondi) = Velocità effettiva TCP massima in bps

Mentre potresti avere una rete Gigabit, un singolo flusso TCP non sarà probabilmente in grado di raggiungere tale livello.

Ecco una semplice tabella presumendo che tu abbia le dimensioni predefinite della finestra TCP 65535Byte in Vista

RTT 10 ms => throughput TCP = 52428000 bps = 52 Mbps

RTT 20 ms => throughput TCP = 26214000 bps = 26 Mbps

RTT 50 ms => throughput TCP = 10485600 bps = 10 Mbps

RTT 100 ms => throughput TCP = 5242800 bps = 5,2 Mbps

RTT 150 ms => throughput TCP = 3495200 bps = 4.3 Mbps

RTT 200 ms => throughput TCP = 2621400 bps = 2,5 Mbps

RTT 300 ms => throughput TCP = 1747600 bps = 1,7 Mbps

RTT 500 ms => throughput TCP = 1048560 bps = 1 Mbps

A 20 MB / sec o 160 Mb / sec la latenza di andata e ritorno è probabilmente dell'ordine di circa 3 millisecondi. L'unico altro modo per accelerare ciò è utilizzare gli ottimizzatori TCP che eseguono il de-dup sul cavo o uniscono i frammenti in pacchetti più grandi. Su una LAN che probabilmente non ti farà guadagnare molto per le spese. Se stai utilizzando dispositivi SoHo come Linksys o Netgear, la tua latenza viene probabilmente introdotta dalla mancanza di buffer condivisi sullo switch. Se si tratta di uno switch più grande come una porta 24, prova a verificare che i due dispositivi siano collegati allo stesso ASIC. Ciò contribuirà al ritardo della serializzazione, ma non di molto. Se potessi lasciarlo cadere a 2ms otterresti un boost fino a circa 31-32Mbyte / sec. Se si trovano su due switch diversi, non c'è molto che si possa fare senza nuovo hardware.

Non che ciò ti aiuti in questo caso, ma Vista / Windows 7 che parla con un server Windows 2008 utilizzerà SMB2, che è molto più efficiente del semplice SMB e utilizzerà molto più della larghezza di banda della rete. Vedere Miglioramenti delle prestazioni del file server con il protocollo SMB2 in Windows Server 2008 e Prestazioni di rete avanzate con Microsoft Windows Vista e Windows Server 2008 per ulteriori informazioni.

SMB2 è in fase di elaborazione in Samba 4 ma sembra che sia stato eseguito il backport su Samba 3.5 .