Scarse prestazioni di scrittura di NFS


20

Ho due macchine collegate con Ethernet 10Gbit. Lascia che uno di questi sia il server NFS e un altro sarà il client NF.

Test della velocità della rete su TCP con una velocità effettiva di iperf~ 9,8 Gbit / s in entrambe le direzioni, quindi la rete è OK.

Test delle prestazioni del disco del server NFS:

dd if=/dev/zero of=/mnt/test/rnd2 count=1000000

Il risultato è ~ 150 MBytes / s, quindi il disco funziona bene per la scrittura.

Il server /etc/exportsè:

/mnt/test 192.168.1.0/24(rw,no_root_squash,insecure,sync,no_subtree_check)

Il client monta questa condivisione sul locale /mnt/testcon le seguenti opzioni:

node02:~ # mount | grep nfs
192.168.1.101:/mnt/test on /mnt/test type nfs4 (rw,relatime,sync,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.102,local_lock=none,addr=192.168.1.101)

Se provo a scaricare un file di grandi dimensioni (~ 5Gb) sul computer client dalla condivisione NFS, ottengo prestazioni ~ 130-140 MBytes / s che si avvicinano alle prestazioni del disco locale del server, quindi sono soddisfacenti.

Ma quando provo a caricare un file di grandi dimensioni nella condivisione NFS, il caricamento inizia a ~ 1,5 Mbyte / s, aumenta lentamente fino a 18-20 Mbyte / se smette di aumentare. A volte la condivisione "si blocca" per un paio di minuti prima che il caricamento inizi effettivamente, ovvero il traffico tra gli host si avvicina allo zero e se eseguo ls /mnt/test, non ritorna durante un minuto o due. Quindi il lscomando ritorna e il caricamento inizia alla velocità iniziale di 1,5 Mbit / s.

Quando la velocità di upload raggiunge il massimo (18-20 Mbyte / s), corro iptraf-nge mostra ~ 190 Mbit / s di traffico sull'interfaccia di rete, quindi la rete non è un collo di bottiglia qui, così come l'HDD del server.

Cosa ho provato:

1. Configurare un server NFS su un terzo host collegato solo con una scheda NIC Ethernet a 100 Mbit. I risultati sono analogici: DL mostra buone prestazioni e un utilizzo della rete quasi pieno a 100 Mbit, il caricamento non ha prestazioni superiori a centinaia di kilobyte al secondo, lasciando l'utilizzo della rete molto basso (2,5 Mbit / s secondo iptraf-ng).

2. Ho provato a mettere a punto alcuni parametri NFS:

  • sync o async

  • noatime

  • no hard

  • rsizee wsizesono massimi nei miei esempi, quindi ho cercato di ridurli in diversi passaggi fino a 8192

3. Ho provato a cambiare macchine client e server (impostare il server NFS sul client precedente e viceversa). Inoltre, ci sono altri sei server con la stessa configurazione, quindi ho provato a montarli tra loro in diverse varianti. Stesso risultato

4. MTU = 9000, MTU = 9000 e aggregazione dei collegamenti 802.3ad, aggregazione dei collegamenti con MTU = 1500.

5. sintonia sysctl:

node01:~ # cat /etc/sysctl.conf 
net.core.wmem_max=16777216
net.core.rmem_max=16777216
net.ipv4.tcp_rmem= 10240 873800 16777216
net.ipv4.tcp_wmem= 10240 873800 16777216
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_sack = 1
net.core.netdev_max_backlog = 5000

Stesso risultato

6. Montare da localhost:

node01:~ # cat /etc/exports
/mnt/test *(rw,no_root_squash,insecure,sync,no_subtree_check)
node01:~ # mount -t nfs -o sync localhost:/mnt/test /mnt/testmount/

E qui ottengo lo stesso risultato: il download da /mnt/testmount/è veloce, il caricamento su /mnt/testmount/è molto lento, non più veloce di 22 MByte / se c'è un piccolo ritardo prima dell'inizio effettivo del trasferimento. Significa che lo stack di rete funziona perfettamente e il problema è in NFS?

Tutto ciò non ha aiutato, i risultati non differivano significativamente dalla configurazione predefinita. echo 3 > /proc/sys/vm/drop_cachesè stato eseguito prima di tutti i test.

L'MTU di tutti i NICS su tutti e 3 gli host è 1500, nessuna sintonizzazione di rete non standard eseguita. Lo switch Ethernet è Dell MXL 10 / 40Gbe.

Il sistema operativo è CentOS 7.

node01:/mnt/test # uname -a
Linux node01 3.10.0-123.20.1.el7.x86_64 #1 SMP Thu Jan 29 18:05:33 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Quali impostazioni mi mancano? Come far scrivere NFS in modo rapido e senza blocchi?


1
Hai un caso di test piuttosto completo, ma proverei a montarlo sul server stesso e scrivere da lì, in questo modo puoi capire se lo stack NFS o lo stack di rete è in errore. Inoltre, prova a cambiare il server e il client (esporta dal client, monta sul server) e usa un client completamente diverso. rintracciare i processi server / client non ha rivelato nulla?
Dalibor Karlovic

@ DaliborKarlovic Ho provato tutti tranne strace e aggiunto informazioni alla domanda. Il montaggio da localhost funziona lentamente, quindi lo stack e lo switch di rete non sembrano essere in errore. Uso NFS nello spazio kernel e Operation not permittedtento di collegare la strace al processo NFS.
Sergey,

Suppongo che ciò significhi che puoi escludere completamente lo stack di rete (ma per assicurarti di doverlo collegare). Dovresti essere in grado di tracciare qualsiasi processo come utente root se non colpito da un determinato bug .
Dalibor Karlovic

@ DaliborKarlovic Sicuramente cerco di provare come root. Sono in grado di collegarmi a qualsiasi processo di userspace, ma non a quelli di kernelspace. Ma quali informazioni posso ottenere dal suo output? Suppongo che produrrà centinaia di migliaia di righe di output se lo collego a NFS e inizio il caricamento. Devo prestare attenzione ai valori di ritorno diversi da zero?
Sergey,

Hai ragione, non stavo pensando che fosse un processo non-userland. Mi aspetto di vedere cosa sta facendo mentre "si blocca" all'inizio del trasferimento, potrebbe essere qualcosa di banale come una ricerca DNS inversa non configurata correttamente.
Dalibor Karlovic

Risposte:


3

Si utilizza l'opzione di sincronizzazione nella propria dichiarazione di esportazione. Ciò significa che il server conferma le operazioni di scrittura solo dopo che sono state effettivamente scritte sul disco. Dato che hai un disco rotante (cioè nessun SSD), ciò richiede in media almeno 1/2 giro del disco per operazione di scrittura, che è la causa del rallentamento.

Utilizzando l'impostazione asincrona, il server riconosce immediatamente l'operazione di scrittura sul client quando viene elaborata ma non ancora scritta sul disco. Questo è un po 'più inaffidabile, ad es. In caso di mancanza di corrente quando il client ha ricevuto un riconoscimento per un'operazione che non è avvenuta. Tuttavia, offre un enorme aumento delle prestazioni di scrittura.

(modifica) Ho appena visto che hai già testato le opzioni asincrono vs sincronizzazione. Tuttavia, sono quasi sicuro che questa sia la causa del tuo problema di degrado delle prestazioni: una volta avevo esattamente la stessa indicazione con una configurazione idencitcal. Forse lo provi di nuovo. Hai fornito l'opzione asincrona nell'istruzione di esportazione del server E nell'operazione di montaggio sul client contemporaneamente?


+1 La spiegazione più probabile è che la sincronizzazione non sia stata disabilitata correttamente.
David Schwartz,

2

Può essere un problema correlato alla dimensione e alla latenza dei pacchetti. Prova quanto segue:

Il rapporto riporta i tuoi risultati.


Ho provato i jumbo frame con MTU = 9000, ma i risultati sono stati gli stessi. Ho anche provato l'aggregazione dei collegamenti con 802.3ad, ancora nessuna modifica. Quindi ho ripristinato tutte queste impostazioni per avvicinarmi il più possibile allo stato predefinito. Inoltre ho provato a sintonizzarlo net.core.*e net.ipv4.*sysctls, ma forse ho fatto troppo pochi esperimenti. OK, farò altri test e riferirò.
Sergey,

Ho provato ancora una volta a mettere a punto sysctls sia sul server che sul client, ma questo non ha aiutato.
Sergey,

Hai provato con UDP come protocollo di trasporto?
shodanshok,

Ho provato UDP (proto = udp nelle opzioni di montaggio), ma funziona anche 1-2 MByte / s più lentamente di TCP. Il risultato è stato lo stesso montaggio da localhost e da host remoto.
Sergey,

2

http://veerapen.blogspot.com/2011/09/tuning-redhat-enterprise-linux-rhel-54.html

La configurazione dello scheduler Linux su sistemi con RAID hardware e la modifica del valore predefinito da [cfq] a [noop] offre miglioramenti I / O.

Utilizzare il comando nfsstat per calcolare la percentuale di letture / scritture. Impostare il rapporto cache del controller RAID in modo che corrisponda.

Per carichi di lavoro pesanti è necessario aumentare il numero di thread del server NFS.

Configura i thread nfs per scrivere senza indugio sul disco usando l'opzione no_delay.

Di 'al kernel di Linux di svuotare il più rapidamente possibile in modo che le scritture siano mantenute le più piccole possibili. Nel kernel di Linux, la frequenza di writeback delle pagine sporche può essere controllata da due parametri.

Per scritture del disco più veloci, utilizzare l'opzione data = journal del filesystem e impedire gli aggiornamenti ai tempi di accesso ai file che di per sé danno come risultato ulteriori dati scritti sul disco. Questa modalità è la più veloce quando i dati devono essere letti e scritti su disco nello stesso momento in cui supera le altre modalità

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.