Perché vedo un throughput di trasferimento SMB così basso?


10

Ok, c'è un po 'di più nella storia di quanto il titolo implichi.

Background e ambiente : sto copiando diversi TB da un vecchio server Ubuntu a un nuovo server Windows 2012 su SMB. (Tecnicamente, è l'hardware delle materie prime, ma sono server da queste parti.) Tutti sono su una LAN gigabit e la vecchia scatola Ubuntu ha un'interfaccia legata. Credo che il server Ubuntu abbia due schede Ethernet Rosewill PCI-e 1x e che il server Windows abbia una scheda Ethernet PCI ragionevolmente bella.

Il computer di destinazione (il server Windows) esegue un lotto di memoria con parità su unità 4x 2 TB. Sta eseguendo il nuovo ReFS di Microsoft. Il computer di origine (il server Ubuntu) esegue un mirror RAID software. Funziona bene con EXT4.

I due server funzionano attraverso un singolo switch gigabit. Ho provato a rompere il legame sul computer di origine (Ubuntu) senza alcun miglioramento.

Problema : non ho problemi a trasferire a velocità ragionevoli da altri computer al server Windows. Altri computer possono contenere 50-80 MB / s senza troppe difficoltà, ma il trasferimento da quel server Ubuntu raggiunge un massimo di 20 MB / s. 4 + TB a 20 MB / s richiede molto tempo (qualcosa come 2,3 giorni) e mi chiedo cosa posso fare per capire dov'è il collo di bottiglia.

Sintomi : la CPU su entrambi i computer è piuttosto minima e certamente non è proibitiva. I dischi rigidi su entrambi i computer sono attivi ma non sommersi e CPU IOwait è quasi lo 0% almeno sul server Ubuntu.

Ho fatto una traccia di Wireshark per 35 secondi (presumibilmente abbastanza a lungo per assicurarmi che tutti gli ACK fossero per nuovi pacchetti) e ho notato che c'erano alcune cose che non mi aspettavo. (1) Non c'erano checksum per gli ACK (e alcuni pacchetti SMB) da Windows a Ubuntu. Tuttavia, Wireshark afferma che ciò potrebbe essere dovuto a "offload del checksum IP". Ok, ho una bella carta lì dentro. Suppongo che la scheda di rete sia in grado di eseguire calcoli di checksum. Belle. Andando avanti ... (2) "TCP ha verificato il segmento invisibile." Questo con cui ho un problema. Il numero ACK rientra in un intervallo accettabile da quello che posso dire e spesso ci sono enormi blocchi di questi messaggi. Forse Wireshark è troppo lento?

Riepilogo : la velocità di trasferimento fa schifo (20 MB / s su Gigabit Ethernet) e non so perché. Wireshark afferma che Windows sta ACKing cose che non sono mai state inviate da Ubuntu.

Indovina : la mia ipotesi iniziale è che le carte Rosewill più economiche vengano sommerse. La mia seconda ipotesi è che le cose simili al software RAID da un lato o dall'altro vengano inondate di cose da fare.


2
Quali velocità ottieni copiando dal server Ubuntu su uno dei desktop (non Server 2012)? Forse WinXP o Win7? Ho avuto grossi problemi con la firma dei pacchetti e la crittografia con SMB con Server 2008 e versioni successive.
Dom

Aggiornamento: ho dovuto riavviare (grazie al panico del kernel). Sfortunatamente il sistema ora ha il panico del kernel ad ogni avvio. Ho tirato fuori la mia fedele copia di Knoppix e montato le unità, e ora tutto è a posto e dandy. Ora sto copiando su SSH e ancora non so dove sia il collo di bottiglia. sshdsta consumando il 60% di un processore sul lato Knoppix. In ogni caso, il mio trasferimento è in fase di completamento. @Dom: ora che me lo dici, non ricordo di aver messo tutti quei dati lì molto più velocemente di 30 Mbps in primo luogo.
Andy,

2
@LorenzoVonMatterhorn, si prega di evitare l'uso di accorciatori di URL.
Cristian Ciupitu,

Sei sicuro che non sia un problema con i tuoi dischi?
MariusMatutiae,

2
Windows ha implementato una versione molto veloce del protocollo SMB (SMB 2) negli ultimi 4-5 anni, che è molto meno loquace e più efficiente sulla rete. Non so di persona quando quei cambiamenti arrivarono a Samba, ma sembra che Ubuntu precedente abbia una Samba più vecchia e forse Knoppix ne abbia una versione più recente.
uSlackr,

Risposte:


1

Il divario in termini di prestazioni corrisponde a un'esperienza comune quando Samba (non sono sicuro che sia ancora l'impostazione predefinita; è stata per molto tempo) è configurata con una dimensione predefinita del buffer del socket di lettura e scrittura di 1024 byte.

Lo vedevo spesso con macchine Linux e Mac. Spero che non sia ancora così.

Esiste un argomento relativo all'opzione socket nel file di configurazione di samba in cui è possibile impostare la dimensione del buffer socket di lettura e scrittura. Suggerire di impostare entrambi a 8192 byte (8 KiB). 4 o 8 KB sono spesso simili, ma non l'ho provato su un collegamento Gigabit.

Inoltre, non aspettarti che una singola connessione TCP tragga vantaggio da un collegamento collegato, il traffico passerà quasi sempre attraverso uno dei collegamenti; altrimenti ti ritroverai con molti pacchetti fuori servizio da gestire; quindi aspettatevi un vantaggio di bilanciamento del carico quando assistete più clienti. Anche in questo caso, dovresti cercare le diverse modalità di legame e sapere che per almeno il legame "mode 4" (IEEE 802.3ad), ci sono fondamentalmente due modalità di hash di trasmissione, che determinano su quale interfaccia slave inviare. Esistono hash di livello 2 (impostazione predefinita) e hash di livello 3. Se invii la maggior parte dei tuoi dati tramite gateway, l'hash di livello 2 non verrà distribuito correttamente, poiché l'indirizzo MAC del gateway sarà lo stesso. Prendi invece in considerazione l'utilizzo del layer 3.


0

Una volta avevo due schede Ethernet in un computer Ubuntu e per qualche motivo non funzionava correttamente - sembravano entrambe in competizione per gli stessi pacchetti, quindi a volte avrei ricevuto una risposta a volte no, a seconda che l'altra scheda di rete avesse afferrato il pieno. Era strano. Devo averlo configurato in modo errato in qualche modo, ma avrei pensato che avrebbe funzionato. Le carte avevano ovviamente un indirizzo IP univoco.

Ad ogni modo, sarebbe semplice per te provarlo con UNA SOLO scheda Ethernet nella macchina connessa alla rete solo per escluderlo.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.