Perché esiste una differenza di velocità di scrittura tra dd, cp, rsync e macOS Finder su un'unità SMB3?

Tl; dr - Non riusciamo a trovare il motivo della velocità di scrittura limitata di 60 MB / sec sul nostro NAS tramite SMB e AFP da due diversi client Mac. In confronto: un vecchio laptop Windows 7 nella stessa rete scrive costantemente 100 MB / sec.

Se leggi questa domanda per la prima volta, passa alla sezione Aggiornamento 4 . rsyncè il motivo principale della bassa velocità, anche se non capiamo perché (per un singolo file!).

Domanda originale: trova il collo di bottiglia della velocità SMB3 / NAS con Mac OS 10.11.5 e versioni successive

Abbiamo testato tramite rsync --progress -a /localpath/test.file /nas/test.filesu macOS e le informazioni sulla copia di Windows.

Il NAS è un DS713 + che esegue l'attuale DSM 6.0.2 (testato anche con 5.x), con due NAS HATA GST Sstar 4 TB (HDN724040ALE640) in RAID1 con solo componenti Gigabit Ethernet e nuovi cavi Ethernet (almeno Cat5e).

I client Mac per primi hanno fatto solo 20 MB / sec. Ma l'applicazione della signing_required=nocorrezione ( qui descritta ) ha spinto la velocità di scrittura a 60 MB / sec tramite SMB2 e SMB3. AFP offre anche circa 60 MB / sec. Il risultato varia circa 5 MB / sec a seconda del protocollo e del client (Mac).

Cosa abbiamo già provato:

Rete

1. Prestazioni di rete testate tramite iperf3. Risultato: 926 Mbit / s. Sembra buono.
2. Ho provato interfacce di rete Dual Link Aggregation / Bonded. Nessun cambiamento.
3. MTU aumentato a 6000 e 9000. Nessuna modifica.
4. Controllato tutti i cavi. Tutto bene almeno Cat5e, in buone condizioni.

dischi

1. Controllato SMART Sembra sano.
2. Velocità di scrittura testata direttamente su disco con dd if=/dev/zero of=write.test bs=256M count=4varie impostazioni bse count(128/8, 512M / 2, 1024/1). Risultato: circa 120 MB / s (a seconda della dimensione / conteggio dei blocchi)

SMB / AFP

1. Benchmark SMB2, SMB3 e AFP confrontati. Circa uguale.
   Vedi aggiornamento di seguito: metodo errato utilizzato per escludere l'implementazione SMB di macOS. SMB su Windows è più veloce, le nuove impostazioni SMB fornite con macOS 10.11 e 10.12 potrebbero essere la ragione.
2. Ho provato a modificare le impostazioni SMB, comprese le opzioni socket (seguendo queste istruzioni )
3. Ho provato diverse versioni di impostazioni ack ritardate e rsync --sockopts=TCP_NODELAY(commenti)

Nessun cambiamento significativo della velocità di scrittura. Abbiamo ricontrollato che la configurazione era davvero caricata e stavamo modificando il giusto smb.conf .

Sistema

1. Caricamento CPU e RAM guardato. Niente è al massimo. CPU circa il 20%, RAM circa il 25% durante il trasferimento.
2. Testato lo stesso NAS con DSM 5.xx in una configurazione quasi pronta all'uso. Nessun software aggiuntivo installato. Nota: ne abbiamo due in diverse località. Sono sincronizzati tramite CloudSync di Synology. Stesso risultato
3. Disattivato tutto ciò che non è necessario che potrebbe attingere risorse di sistema.

Pensiamo che si tratti di un'impostazione piuttosto predefinita, senza adattamenti elaborati, client o componenti di rete. Secondo le metriche Synology pubblica, il NAS dovrebbe eseguire da 40 MB / sa 75 MB / s più velocemente. Ma non possiamo trovare il collo di bottiglia.

Clienti / NAS

I client Mac sono un MacPro 5,1 (scheda di rete standard cablata, in esecuzione 10.12.3 (16D32)) e un MacBookPro10,1 (adattatore di rete Thunderbolt, in esecuzione 10.11.6) a circa 2 m di cavo dal NAS, che passano sullo stesso switch gigabit come laptop Windows nel test.

Abbiamo due di questi NAS in posizioni diverse e i risultati sono identici. Il secondo NAS è più o meno l'impostazione predefinita di fabbrica (nemmeno il software di terze parti installato). Solo due dischi formattati RAID1, EXT4 sincronizzati con l'altro NAS tramite Synology CloudSync. Siamo arrivati ​​al punto di collegarci direttamente al NAS senza lo switch, stesso risultato.

Aggiornamento importante

Il metodo utilizzato per escludere l'implementazione SMB di macOS / OS X era errato. L'ho provato tramite una macchina virtuale, supponendo che avrebbe usato la propria versione di SMB, ma ovviamente il traffico viene consegnato a macOS, correndo attraverso la sua versione di SMB.

Utilizzando un laptop Windows sono stato in grado di raggiungere una media di 100 MB / s. L'indicazione dell'implementazione / degli aggiornamenti SMB forniti con 10.11 e 10.12 può causare scarse prestazioni. Anche se signing_requiredimpostato su no.

Sarebbe bello se qualcuno potesse indicare alcune ulteriori impostazioni che potrebbero essere cambiate con gli aggiornamenti e che potrebbero influire sulle prestazioni.

Aggiornamento 2: nuovi approfondimenti

AndrewHenle ha sottolineato nei commenti che dovrei indagare in dettaglio sul traffico usando Wireshark per ulteriori approfondimenti.

Ho quindi eseguito sudo tcpdump -i eth0 -s 65535 -w tcpdump.dumpsul NAS, trasferendo due file di test uno con 512 MB e uno con 1 GB. E ispezionò la discarica con Wireshark.

Cosa ho trovato:

1. Sia OS X che Windows sembrano usare SMB2 sebbene SMB3 sia abilitato sul NAS (almeno secondo Wireshark).
2. OS X sembra attenersi all'MTU . I pacchetti hanno 1514 byte che portano a un maggior sovraccarico di rete e ai pacchetti inviati (visibili nei dump).
3. Windows sembra inviare pacchetti fino a 26334 byte (se leggo i dati correttamente! Verificare.) Anche se l'MTU non lo consente, poiché è impostato su 1500 sul NAS, l'impostazione massima sarebbe 9000 lì (anche Synology utilizza l'impostazione 1500 nei loro test).
4. Cercare di forzare macOS a utilizzare SMB3 aggiungendo smb_neg=smb3_onlya /etc/nsmb.conf non ha funzionato o almeno non ha portato a trasferimenti più veloci.
5. L'esecuzione rsync --sockopts=TCP_NODELAYcon varie combinazioni di impostazioni ack ritardate TCP (da 0 a 3) non ha avuto alcun effetto (Nota: ho eseguito tcpdump con l'impostazione ack predefinita di 3).

Ho creato 4 dump come file .csv, 2 durante la copia di 512 MB (test-2.file) e 2 durante la copia di 1024 MB (test.file). Puoi scaricare le esportazioni di Wireshark qui (25,2 MB). Sono zippati per risparmiare spazio e chiamati autoesplicativamente.

Aggiornamento 3 - output di smbutil

Output di smbutil statshares -acome richiesto da harrymc nei commenti.

==================================================================================================
SHARE                         ATTRIBUTE TYPE                VALUE
==================================================================================================
home
                              SERVER_NAME                   server-name._smb._tcp.local
                              USER_ID                       502
                              SMB_NEGOTIATE                 SMBV_NEG_SMB1_ENABLED
                              SMB_NEGOTIATE                 SMBV_NEG_SMB2_ENABLED
                              SMB_NEGOTIATE                 SMBV_NEG_SMB3_ENABLED
                              SMB_VERSION                   SMB_3.0
                              SMB_SHARE_TYPE                DISK
                              SIGNING_SUPPORTED             TRUE
                              EXTENDED_SECURITY_SUPPORTED   TRUE
                              LARGE_FILE_SUPPORTED          TRUE
                              OS_X_SERVER                   TRUE
                              QUERYINFO_NOT_SUPPORTED       TRUE
                              DFS_SUPPORTED                 TRUE
                              MULTI_CREDIT_SUPPORTED        TRUE

--------------------------------------------------------------------------------------------------

Nota su questo: sono sicuro che SIGNING_SUPPORTEDessere truequi non significa che l'impostazione nella configurazione non funziona. Ma solo che è supportato dal NAS. Ho verificato tre volte che la modifica delle signing_requiredimpostazioni nella mia configurazione ha un effetto sulla velocità di scrittura (~ 20 MB / s quando sintonizzato, ~ 60 MB / s quando spento).

Aggiornamento 4 - Samba Wars: una nuova speranza

Sembra un po 'imbarazzante, ma il problema principale qui - di nuovo - sembra essere la misurazione.

Risulta che rsync --progress -acosta circa 30 MB / s di velocità di scrittura. Scrivere con dddirettamente sulla condivisione SMB e utilizzare time cp /local/test.file /NAS/test.filesono più veloci a circa 85-90 MB / se apparentemente il modo più veloce per copiare è macOS Finder a circa 100 MB / s (che è anche il metodo più difficile da misurare, poiché non esiste indicatore di temporizzazione o velocità - chi ne ha bisogno, giusto? o_O). Lo abbiamo misurato copiando prima un file da 1 GB e quindi un file da 10 GB, utilizzando un cronometro.

Cosa abbiamo provato dall'ultimo aggiornamento di questa domanda.

1. Copia dal client Mac al client Mac. Entrambi hanno SSD (MacPro scrive con 250 MB / s sul proprio disco, MacBook Pro con 300 MB / s). Risultato: 65 MB / s scarsi tramite la ddscrittura da MacBook Pro a MacPro ( rsync25 MB / s). Vedere i 25 MB / s è stato il momento in cui abbiamo iniziato a mettere in discussione rsync. Ancora 65 MB / s sono estremamente lenti. Quindi l'implementazione delle PMI su macOS sembra ... beh, discutibile.
2. Ho provato diverse impostazioni di ack con dd e cp - senza fortuna.
3. Finalmente abbiamo trovato un modo per elencare tutte le opzioni nsmb.conf disponibili. È semplice man nsmb.conf. Attenzione, la versione online è obsoleta!

Quindi abbiamo provato alcune altre impostazioni, tra cui:

notify_off=yes
validate_neg_off=yes
read_async_cnt=16
write_async_cnt=16
dir_cache_async_cnt=40
protocol_vers_map=4
streams=no
soft=yes

Nota: non smb_neg=smb3_onlyè - come mi aspettavo - un'impostazione valida. protocol_vers_map=4dovrebbe essere l'equivalente valido.

Comunque, nessuna di queste impostazioni ha fatto la differenza per noi.

Nuove domande a colpo d'occhio

1. Perché rsync è un modo così costoso per copiare un file (1!). Non c'è molto da sincronizzare / confrontare qui, vero? Il tcpdump non indica neanche un possibile sovraccarico.

2. Perché dde cppiù lento del macOS finder durante il trasferimento su una condivisione SMB? Sembra che quando si copia con Finder ci sono significativamente meno riconoscimenti nella comunicazione TCP. (Ancora una volta: l'impostazione ack, ad esempio, delayed_ack=1non ha fatto alcuna differenza per noi.)

3. Perché Windows sembra ignorare l'MTU, inviando pacchetti TCP significativamente più grandi e quindi meno, con il risultato delle migliori prestazioni, rispetto a tutto il possibile tramite macOS.

Ecco come appaiono i pacchetti da macOS (costantemente 1514)

"TCP","1514","[TCP segment of a reassembled PDU]"
"TCP","66","445  >  56932 [ACK] Seq=6603 Ack=35239 Win=4505 Len=0 TSval=520980697 TSecr=650208630"

E questo proviene da Windows (fino a 26334, di dimensioni variabili)

"SMB2","1466","Write Request Len:65536 Off:196608 File: test.file"
"TCP","26334","[TCP segment of a reassembled PDU]"
"TCP","7354","[TCP segment of a reassembled PDU]"
"TCP","54","445  >  49220 [ACK] Seq=6831 Ack=267030 Win=4074 Len=0"

Puoi scaricare .csv completo qui (25,2 MB), i nomi dei file spiegano cosa è stato copiato (sistema operativo, metodo di trasferimento e dimensione del file).

1. domanda simile ma con risposte interessanti, potrebbe essere che puoi controllare questa discussione specialmente sul commento 5: https://bugzilla.samba.org/show_bug.cgi?id=8512#c5

Qui cita "Peter van Hooft". Anche se non sono sicuro testare la base su cosa / quale dist di Linux. e anche la versione di rsync. Tuttavia: 1. ci ha pensato di provare - sparse flag se fosse possibile aumentare le prestazioni. 2. ha testato il protocollo NFS ma ha riscontrato lo stesso problema di velocità, quindi l'IT potrebbe non essere il motivo del protocollo (SMB2 / 3, AFP, ecc.).

Usiamo rsync per copiare i dati da un file server a un altro utilizzando i montaggi NFS3 su un collegamento da 10 Gb. Abbiamo scoperto che aumentare le dimensioni del buffer (come test rapido) aumenta le prestazioni. Quando si utilizza --sparse, ciò aumenta le prestazioni con un fattore di cinquanta, da 2 MB a 100 MB.

2. Ecco un'altra interessante ispezione sulle prestazioni di rsync. https://lwn.net/Articles/400489/

LWN.net ha una conclusione che il problema delle prestazioni può essere rilevante per il kernel anche l'articolo pubblicato nel 2010 e non possiamo cambiare su NAS o MacOS. Tuttavia, questo articolo ci dà un'idea del fatto che il problema del kernel può essere causato dal calcolo del checksum (la mia ipotesi).

Una cosa è chiara: dovrei aggiornare il kernel sul mio sistema Mythtv. In generale, i kernel 2.6.34 e 2.6.35-rc3 offrono prestazioni migliori rispetto al vecchio kernel 2.6.27. Ma, armeggiando o no, rsync non può ancora battere un semplice cp che copia a oltre 100 MiB / s. Infatti, rsync ha davvero bisogno di molta potenza della CPU per semplici copie locali. Alla massima frequenza, cp richiede solo 0,34 + 20,95 secondi di tempo CPU, rispetto ai 70 + 55 secondi di rsync.

anche citare commenti ha questo:

Si noti che rsync verifica sempre che ogni file trasferito sia stato correttamente ricostruito sul lato ricevente controllando un checksum di tutto il file generato durante il trasferimento del file

aggiornamento 1 : errore mio, questa descrizione è per --checksum. controlla qui: [Migliorata la descrizione dell'opzione --checksum.] PS, non ho abbastanza reputazione per pubblicare più di 2 link.

ma non riesco a trovare la stessa descrizione dalla pagina man di rsync, quindi immagino che qualcuno stia parlando sotto Bold:

Rsync trova i file che devono essere trasferiti usando un algoritmo di "controllo rapido" (per impostazione predefinita) che cerca i file che sono cambiati nelle dimensioni o nell'ultima modifica. Eventuali modifiche negli altri attributi conservati (come richiesto dalle opzioni) vengono apportate direttamente sul file di destinazione quando il controllo rapido indica che non è necessario aggiornare i dati del file.

Pertanto, confronta con cp / tar / cat, se usiamo rsync per copiare un mucchio di file piccoli o grandi potrebbe causare problemi di prestazioni. MA perché non sono in grado di leggere il codice sorgente di rsync, quindi non posso confermare che questa sia la ragione ultima.

la mia idea è di continuare a controllare:

1. Quale versione di rsync sta usando awenro per i test? Potresti aggiornare all'ultima versione?
2. vediamo quale output quando usi --stats e -v con --debug = FLAGS

bandiere

--stats Questo dice a rsync di stampare un set dettagliato di statistiche sul trasferimento dei file, permettendoti di dire quanto sia efficace l'algoritmo rsync per i tuoi dati.

--debug = FLAGS Questa opzione consente di avere un controllo accurato sull'output di debug che si desidera vedere. Il nome di un singolo flag può essere seguito da un numero di livello, con 0 che significa silenziare quell'output, 1 è il livello di output predefinito e numeri più alti aumentano l'output di quel flag (per quelli che supportano livelli più alti). Usa --debug = help per vedere tutti i nomi dei flag disponibili , cosa emettono e quali nomi di flag vengono aggiunti per ogni aumento nel livello dettagliato.

alla fine, consiglierei di leggere questo post supplementare per ottenere maggiori informazioni.
"Come trasferire grandi quantità di dati tramite la rete" moo.nac.uci.edu/~hjm/HOWTO_move_data.html

Rsync / ssh crittografa la connessione smb no, se ricordo bene. Se è solo un file, un sistema potrebbe essere in grado di leggere quel file e l'altro no. Si noti inoltre che per avere MTU superiore al 1514 è necessario abilitare i pacchetti "giganti" / "Jumbo Frame", il fatto che i pacchetti debbano essere ulteriormente ridotti può implicare che vi sia un sovraccarico per "reimballare" il pacchetto. La seconda cosa da notare è che "giganti" / "Jumbo Frame" devono essere abilitati su entrambe le estremità E TUTTO TRA.

1514 sono i normali frame Ethernet. I frame 6k-9k sono chiamati giganti o "Jumbo Frame" a seconda del sistema operativo / dell'applicazione

Ho una media di 80 MB / s tra il mio nas (un PC con VM, uno dei VM è il NAS) e la mia stazione (un pc) con sftp (usando sshfs) [giganti non abilitati] e il dispositivo in mezzo è un microtik 2011 (andando solo tru switch chip)

Ricorda che MTU è negoziato tra due punti e che lungo un percorso potresti avere diversi MTU a diversa capacità e che l'MTU sarà il più basso disponibile.

modifica: SMB non è molto efficiente per i trasferimenti di file.