filesystem per milioni di piccoli file

44

Quale filesystem Linux sceglieresti per la migliore velocità nel seguente scenario:

cento milioni di file
~ 2k dimensioni del file in media
> 95% accesso in lettura
accesso piuttosto casuale
alta concorrenza (> 100 processi)

Nota: i file sono memorizzati in un albero gerarchico profondo per evitare directory di grandi dimensioni. Ogni directory foglia contiene circa mille file.

Come lo confronteresti?

linux filesystems benchmark

— bene
fonte

3

Sono necessarie alcune informazioni aggiuntive. Ad esempio, stai memorizzando tutti i file in una directory flat o in directory nidificate (ordinate)? Ciò può avere un notevole impatto sulle prestazioni sui tempi di accesso ai file. La setacciatura di 100.000.000 di voci in una disposizione "piatta" comporterà un notevole sovraccarico indipendentemente dal tipo di FS; nel migliore dei casi, stai cercando una ricerca ad albero di qualche tipo, che richiede ancora più ricerche per arrivare al tuo file. Se si catagorizzano i file in sottodirectory, il tempo di accesso accelera notevolmente in quanto vi sono meno voci da cercare a ciascun livello.

— Avery Payne,

Si accede al file in serie o contemporaneamente?

— Steve Schnepp,

19

Ecco alcuni risultati confrontando tutti i principali FS di Linux con Bonnie ++ che puoi usare come punto di partenza.

In termini di ricerche casuali, Reiser vince, seguito da EXT4, seguito da JFS. Non sono sicuro se questo sarà correlato esattamente alle ricerche di directory, ma sembra che sarebbe un indicatore. Dovrai fare i tuoi test per quello specifico. EXT2 batte tutto per i tempi di creazione dei file, probabilmente a causa della mancanza di un diario, EXT4 batte comunque tutto tranne Reiser che potresti non voler usare a causa dello stato attuale di hans reiser.

Potresti voler esaminare le unità che supportano NCQ e assicurarti che l'installazione sia configurata per usarlo. Sotto pesanti ricerche dovrebbe fornire un aumento di velocità.

Infine, assicurati che la tua macchina abbia un sacco di ram. Dato che i file non vengono spesso aggiornati, Linux finirà per memorizzare nella cache la maggior parte di essi su RAM se ha spazio libero. Se i tuoi schemi di utilizzo sono corretti, questo ti darà un enorme aumento di velocità.

— Andrew Cholakian
fonte

1

il problema di bonnie ++ è che non prova nemmeno approssimativamente il mio scenario di utilizzo

— bene,

2

Hai senso non testare le ricerche di directory, ma onestamente, se questo è il tuo choke point, è meglio scaricare i dati in un vero database. I filesystem non funzionano altrettanto bene sui piccoli oggetti che la maggior parte dei database sono progettati per l'uso

— Andrew Cholakian,

7

@AndrewCholakian Link ora è morto.

— Don Scott,

8

Sono d'accordo con la maggior parte di quello che ha detto Andrew, se non che mi sento di raccomandare Reiser4 il più vecchio (ma meglio supportati) o ReiserFS . Come indicano questi test (e la documentazione per ReiserFS), è progettato per la situazione che stai chiedendo (un gran numero di piccoli file o directory). Ho usato ReiserFS in passato con Gentoo e Ubuntu senza problemi.

Per quanto riguarda lo stato di Hans Reiser, non lo vedo come un problema con il codice o la stabilità del file system stesso. Reiser4 è persino sponsorizzato sia da DARPA che da Linspire, quindi mentre concordo sul fatto che l'ulteriore sviluppo del file system Reiser è indeterminato, non credo che dovrebbe essere un fattore decisivo se qualcuno dovrebbe usarlo o meno.

— Mike
fonte

3

Ho usato ReiserFS per molto tempo. In realtà, lo sto ancora usando su un vecchio server Gentoo che non sono ancora riuscito a reinstallare. Questa installazione ha 4 anni a maggio. Quello che posso dirti è che è rallentato in modo significativo. Tale fenomeno si è verificato nel tempo su tutti i file system che utilizzano ReiserFS in uso in lettura + scrittura attiva su tutte le macchine che avevano tali file system, senza eccezioni, quindi se si desidera utilizzarlo per un periodo di tempo prolungato è qualcosa da mantenere in mente. Mi sono allontanato da esso, usando XFS per filesystem di grandi dimensioni ora.

— Mihai Limbăşan,

3

So che questa non è una risposta diretta alla tua domanda, ma in questi casi penso che un database potrebbe essere più adatto per ospitare questo. I file di piccole dimensioni possono essere archiviati in formato binario in una tabella di database e recuperati su wil. Il software che utilizza questi file dovrebbe essere in grado di supportare questo però ...

— Jeroen Landheer
fonte

1

Che cos'è un file system, se non solo un database gerarchico? La tua proposta aggiunge livelli di astrazione, complessità e software che probabilmente non sono garantiti. Inoltre, il proprietario della domanda sta compiendo il suo compito con "UNIX Philosophy" di cui sospetto che non ti piaccia essere un tipo Windows?

— Stu Thompson,

3

Prima di tutto, non ho nulla contro Unix o qualsiasi altra cosa in quella zona. Esistono grandi differenze tra file system e database ed è per questo che sono state sviluppate entrambe le tecnologie. I database sono progettati per funzionare con un'enorme quantità di piccole entità, in cui svolgono un lavoro migliore rispetto alla maggior parte dei file system. Stavo solo sottolineando che potrebbe esserci un'altra strada che puoi prendere con questo.

— Jeroen Landheer,

1

Ed è molto più facile "pulire / aspirare" un file db che deframmentare un filesystem su linux. La maggior parte / tutte le fs non forniscono tale funzionalità, dicendo che non è necessario. Notando il commento di Mihai sopra, però, puoi vedere che non è strettamente vero.

— Gringo Suave,

3

Qualcuno su Unix StackExchange ha creato un benchmark (con sorgente) per testare proprio questo scenario:

D: Qual è il file system Linux più performante per l'archiviazione di molti file di piccole dimensioni (HDD, non SSD)?

Le migliori prestazioni di lettura sembrano provenire da ReiserFS.

— thenickdude
fonte

Btrfs sembra avere risultati migliori o comparabili in tutto tranne che eliminare. Ma quanto spesso elimini i file 300k? Mi è piaciuto rfs in passato, ma btrfs potrebbe essere una scommessa migliore per il futuro.

— Gringo Suave,

3

Nella mia esperienza, ext2 soffia ext4 fuori dall'acqua per piccoli file. Se non ti interessa scrivere integrità, è fantastico. Ad esempio, Subversion crea moltissimi file di piccole dimensioni, che ext4 e altri filesystem (XFS) si strozzano (eseguono un processo cron che risincronizza i dati su ext4 da ext2 ogni mezz'ora o così praticamente risolve il problema).

L'esecuzione di questi comandi rende ext2 ancora più veloce (anche se la maggior parte di queste opzioni rende instabile il file system dopo un arresto, a meno che non si esegua la sincronizzazione prima che si blocchi. Questi comandi non hanno quasi alcun effetto su ext4 con file di piccole dimensioni.

echo 15 > /proc/sys/vm/swappiness
echo 10 > /proc/sys/vm/vfs_cache_pressure
echo 99 > /proc/sys/vm/dirty_ratio
echo 50 > /proc/sys/vm/dirty_background_ratio
echo 360000 > /proc/sys/vm/dirty_expire_centisecs
echo 360000 > /proc/sys/vm/dirty_writeback_centisecs
echo "2000" > /proc/sys/vm/vfs_cache_pressure

— Jason Hall
fonte

1

Immagino ext3 (o ext4), forse JFS sarebbe una buona soluzione. Sarei diffidente con ext4 e btrfs (i filesystem sono difficili - preparatevi con i backup se volete usare le cose più recenti e più recenti).

Ci sono anche vari parametri che puoi modificare durante il tempo di mkfs per ottimizzare il filesystem a tuo piacimento.

Consiglierei sicuramente contro XFS. Non perché è un cattivo file system, ma la creazione / cancellazione è un'operazione costosa su di esso.

Per evitare problemi con le ricerche nella directory, utilizzare uno schema di denominazione intelligente, ad esempio:

<first letter of id>_<last letter of id>/<id>

o schemi simili e più complicati. Ciò accelererà le ricerche nella directory e quindi la velocità di accesso complessiva. (È un vecchio trucco unix, penso che sia tornato da V7)

1

qual è il vantaggio di usare la prima e l'ultima lettera e non solo le prime n lettere?

— Bene,

è solo uno dei possibili schemi - se sarebbe un vantaggio dipende dalla "chiave" utilizzata per l'indicizzazione. Questo particolare schema che avevo visto fare riferimento all'applicazione che memorizzava i dati sulle persone dell'organizzazione e in questo modo hanno una migliore indicizzazione. Come sempre, devi adattarlo ai tuoi dati e quindi profilare fino a trovare risposte esatte :)

1

La maggior parte delle FS si strozzerà con più di 65 KB di file in una directory, penso che sia ancora vero per ext4. I file system Reiser non hanno questo limite (la gente di mp3.com ha pagato per accertarsene). Non sono sicuro di nient'altro, ma questo è uno degli scenari di utilizzo per cui è stato realizzato ReiserFS.

— Ronald Pottol
fonte

1

È ReiserFS, non RieserFS

— Daniel Rikowski il

Questo fine settimana ho avuto un dir su ext4 con 1000000 file. Finché non lo fai lso il completamento con la scheda funziona velocemente. Probabilmente a causa dell'indice.

— Ole Tange,

ext4 ha un'estensione dir_index, che accelera molti file in una directory.

— alfonx,