Prestazioni di trasferimento NFS lente di file di piccole dimensioni

Sto usando Openfiler 2.3 su un disco HP ML370 G5, Smart Array P400, SAS combinato usando RAID 1 + 0.

Ho impostato una condivisione NFS dalla partizione ext3 usando la configurazione basata su Web di Openfiler e sono riuscito a montare la condivisione da un altro host. Entrambi gli host sono collegati usando un collegamento Gigabit dedicato.

Semplice benchmark usando dd:

 $ dd if=/dev/zero of=outfile bs=1000 count=2000000
 2000000+0 records in
 2000000+0 records out
 2000000000 bytes (2.0 GB) copied, 34.4737 s, 58.0 MB/s

Vedo che può raggiungere una velocità di trasferimento moderata (55,0 MB / s).

Ma se copio una directory contenente molti piccoli file ( .phpe .jpg, circa 1-4 kB per file) di dimensioni totali ~ 300 MB, il cpprocesso termina in circa 10 minuti.

NFS non è adatto per il trasferimento di piccoli file come sopra? O ci sono alcuni parametri che devono essere regolati?

Ci sono molte ragioni per cui il trasferimento di molti file di piccole dimensioni sarà sempre più lento del trasferimento di un singolo file di grandi dimensioni. Per una lettura, è più probabile che i file siano sparsi sul disco, richiedendo ricerche ovunque per ottenerli. Come menzionato Evan, ci sono anche metadati coinvolti nel caso di NFS (o di qualsiasi altro file system per quella materia!) Che complica anche le cose.

Puoi provare ad aumentare i tuoi parametri rsizee wsizeal mount NFS e vedere se ciò contribuirà un po 'alle prestazioni. Dai un'occhiata anche a questa domanda sull'ottimizzazione di NFS per la latenza minima in quanto ha molti consigli utili che ti aiuteranno nel caso di molti trasferimenti di file di piccole dimensioni.

Non ho molta esperienza con NFS, ma la mia esperienza con altri protocolli di condivisione di file di rete afferma che le prestazioni soffrono nello scenario "molti piccoli file" quasi universalmente. Stai subendo la latenza di andata e ritorno e su un ampio gruppo di file che la latenza aggiunge.

Hai provato con un file system diverso, come XFS? Ha risolto tutti i miei problemi quando si eseguono quantità estreme di piccoli trasferimenti di blocchi iSCSI. Non ho idea del perché.

Inoltre, iSCSI / NFS è in genere configurato per frame di dati piuttosto grandi (frame jumbo, ecc.), Potrebbe ferirti se stai copiando file di dimensioni ridotte uno alla volta. Forse il taring e poi il trasferimento ti aiuterebbero.

Verifica di utilizzare la connessione TCP ( mount -t nfs -o tcp host: / mount / target ). Le prestazioni sui sistemi moderni non saranno influenzate, ma i piccoli IO possono migliorare in modo significativo se la rete è caricata.

E dovresti anche provare qualche altro filesystem; ext3 è sostanzialmente il più lento di tutti. È solido, ben noto, ma non è abbastanza adatto per un file server. XFS è molto meglio e reiserfs è molto meglio anche in piccoli IO.

Se si desidera trasferire un grande albero di directory di piccoli file su NFS e si può accedere al server, il modo migliore per farlo è creare un file tar che viene automaticamente estratto sul client, come segue:

tar c mydirectory | ssh user @ host tar -xf - -C destdir

In questo modo solo un singolo "file" viene trasferito attraverso la rete e hai immediatamente tutti i tuoi file sull'host.

Solo per aggiungere alla risposta di Evan, hai anche tutto il sovraccarico di creare i metadati (voci di directory, ecc.) Per ogni file su cui stai copiando.

Una soluzione simile alla risposta di Chris sarebbe quella di risincronizzare periodicamente i file con i client. Se si desidera apportare modifiche a due vie, è possibile utilizzare anche all'unisono.

Il problema è che la tua condivisione viene esportata con l' syncopzione (impostazione predefinita). Utilizzare asyncper accelerare notevolmente le scritture. Vedi nfs.sourceforge.net/nfs-howto/ar01s05.html