Quali sono le conseguenze sulle prestazioni di milioni di file in un moderno file system?

Supponiamo di utilizzare ext4 (con dir_index abilitato) per ospitare circa 3 milioni di file (con una dimensione media di 750 KB) e dobbiamo decidere quale schema di cartelle utilizzare.

Nella prima soluzione , applichiamo una funzione di hash al file e usiamo la cartella a due livelli (essendo 1 carattere per il primo livello e 2 caratteri al secondo livello): quindi essendo l' filex.forhash uguale a abcde1234 , lo memorizzeremo su / path / a / bc /abcde1234-filex.for.

Nella seconda soluzione , applichiamo una funzione di hash al file e usiamo la cartella a due livelli (essendo 2 caratteri per il primo livello e 2 caratteri al secondo livello): quindi essendo l' filex.forhash uguale a abcde1234 , lo memorizzeremo su / path / ab / de /abcde1234-filex.for.

Per la prima soluzione avremo il seguente schema /path/[16 folders]/[256 folders]con una media di 732 file per cartella (l'ultima cartella, dove risiederà il file).

Mentre sulla seconda soluzione avremo /path/[256 folders]/[256 folders]con una media di 45 file per cartella .

Considerando che scriveremo / scolleghiamo / leggiamo i file ( ma principalmente leggiamo ) da questo schema (fondamentalmente il sistema di cache nginx), maturerà, in senso prestazionale, se scegliamo una o l'altra soluzione?

Inoltre, quali sono gli strumenti che potremmo usare per controllare / testare questa configurazione?

Il motivo per cui si creerebbe questo tipo di struttura di directory è che i filesystem devono individuare un file all'interno di una directory, e più grande è la directory, più lenta sarà tale operazione.

Quanto più lentamente dipende dalla progettazione del filesystem.

Il filesystem ext4 utilizza un albero B per memorizzare le voci della directory. Una ricerca su questa tabella dovrebbe richiedere O (log n) tempo, che la maggior parte delle volte è inferiore alla tabella lineare ingenua utilizzata da ext3 e dai precedenti filesystem (e quando non lo è, la directory è troppo piccola per essere conta davvero).

Il filesystem XFS usa invece un albero B + . Il vantaggio di questo su una tabella hash o un albero B è che qualsiasi nodo può avere più figli b , dove in XFS b varia e può arrivare fino a 254 (o 19 per il nodo radice; e questi numeri potrebbero non essere aggiornati ). Questo ti dà una complessità temporale di O (log _b n) , un grande miglioramento.

Entrambi questi filesystem possono gestire decine di migliaia di file in una singola directory, con XFS che è significativamente più veloce di ext4 in una directory con lo stesso numero di inode. Ma probabilmente non vuoi una singola directory con inode 3M, poiché anche con un albero B + la ricerca può richiedere del tempo. Questo è ciò che ha portato alla creazione di directory in questo modo, in primo luogo.

Per quanto riguarda le strutture proposte, la prima opzione che hai dato è esattamente ciò che viene mostrato negli esempi di nginx. Funzionerà bene su entrambi i filesystem, anche se XFS avrà ancora un piccolo vantaggio. La seconda opzione potrebbe avere prestazioni leggermente migliori o leggermente peggiori, ma probabilmente sarà abbastanza vicina, anche sui benchmark.

Nella mia esperienza, uno dei fattori di ridimensionamento è la dimensione degli inode data una strategia di partizionamento con nome hash.

Entrambe le opzioni proposte creano fino a tre voci di inode per ciascun file creato. Inoltre, 732 file creeranno un inode che è ancora inferiore ai soliti 16 KB. Per me, questo significa che entrambe le opzioni eseguiranno lo stesso.

Ti applaudo per il tuo hash corto; i sistemi precedenti su cui ho lavorato hanno preso lo sha1sum del file dato e le directory di giunzione basate su quella stringa, un problema molto più difficile.

Certamente entrambe le opzioni aiuteranno a ridurre il numero di file in una directory a qualcosa che sembra ragionevole, per xfs o ext4 o qualunque altro file system. Non è ovvio quale sia meglio, dovrebbe testare per dire.

Il benchmark con la tua applicazione che simula qualcosa come il vero carico di lavoro è l'ideale. Altrimenti, inventati qualcosa che simuli in modo specifico molti piccoli file. A proposito, eccone uno open source chiamato smallfile . La sua documentazione fa riferimento ad altri strumenti.

hdparmfare I / O sostenuti non è così utile. Non mostrerà i molti piccoli I / O o voci di directory giganti associate a moltissimi file.

Uno dei problemi è il modo di scansionare la cartella.

Immagina il metodo Java che esegue la scansione sulla cartella.

Dovrà allocare una grande quantità di memoria e distribuirla in breve tempo, il che è molto pesante per la JVM.

Il modo migliore è di organizzare la struttura delle cartelle nel modo in cui ciascun file si trova nella cartella dedicata, ad esempio anno / mese / giorno.

Il modo in cui viene eseguita la scansione completa è che per ogni cartella esiste una corsa della funzione, quindi JVM uscirà dalla funzione, dislocerà la RAM ed eseguirà nuovamente su un'altra cartella.

Questo è solo un esempio, ma avere una cartella così grande non ha senso.

Ho avuto lo stesso problema. Cerca di archiviare milioni di file in un server Ubuntu in ext4. Ho finito con i miei benchmark. Ho scoperto che la directory flat funziona in modo molto migliore pur essendo molto più semplice da usare:

Ha scritto un articolo .