In che modo il numero di sottodirectory influisce sulle prestazioni di lettura / scrittura del disco su Linux?

Ho un disco formattato EXT3 su un server Linux CentOS. Questa è un'unità dati per le app Web e contiene una directory per ogni account utente (ci sono 25.000 utenti). Ogni cartella contiene file che l'utente ha caricato. Nel complesso, questa unità contiene circa 250 GB di dati.

La strutturazione dell'unità con tutte queste directory influisce sulle prestazioni di lettura / scrittura dell'unità? Incide su qualche altro aspetto delle prestazioni di cui non sono a conoscenza?

C'è qualcosa di intrinsecamente sbagliato o cattivo nella strutturazione delle cose in questo modo? Forse solo la scelta sbagliata del filesystem?

Di recente ho provato a unire due unità dati e ho capito che EXT3 è limitato a 32.000 sottodirectory. Questo mi ha fatto chiedere perché. Sembra sciocco che l'ho costruito in questo modo, considerando che ogni file ha un ID univoco che corrisponde a un ID nel database. Ahimè ...

È facile testare le opzioni per te stesso, nel tuo ambiente e confrontare i risultati. Sì, c'è un impatto negativo sulle prestazioni all'aumentare del numero di directory. Sì, altri filesystem possono aiutare a superare quelle barriere o a ridurne l'impatto.

Il filesystem XFS è migliore per questo tipo di struttura di directory. ext4 probabilmente oggi va bene. L'accesso e le operazioni sulla directory semplicemente rallenteranno all'aumentare del numero di sottodirectory e file. Questo è molto pronunciato in ext3 e non tanto su XFS.

La risposta non è semplice come la scelta del filesystem. I filesystem sani hanno smesso di usare liste lineari per le directory molto tempo fa, il che significa che il numero di voci in una directory non influenza il tempo di accesso ai file ....

tranne quando lo fa.

In effetti, ogni operazione rimane veloce ed efficiente, indipendentemente dal numero di voci, ma alcune attività comportano un numero crescente di operazioni. Ovviamente, fare un semplice lsrichiede molto tempo e non si vede nulla fino a quando tutti gli inode non sono stati letti e ordinati. Fare ls -U(non ordinato) aiuta un po 'perché puoi vedere che non è morto, ma non riduce il tempo in modo percettivo. Meno ovvio è che qualsiasi espansione di caratteri jolly deve controllare ogni singolo file e sembra che nella maggior parte dei casi anche l'intero inode debba essere letto.

In breve: se puoi essere sicuro che nessuna applicazione (incluso l'accesso alla shell) utilizzerà mai un jolly, puoi ottenere enormi directory senza alcun rimorso. Ma se ci potrebbero essere dei caratteri jolly in agguato nel codice, meglio tenere le directory inferiori a mille voci ciascuna.

modifica :

Tutti i moderni filesystem usano buone strutture di dati per grandi directory, quindi una singola operazione che deve trovare l'inode di un file specifico sarà abbastanza veloce anche su enormi directory.

Ma la maggior parte delle applicazioni non esegue solo operazioni singole. La maggior parte di essi eseguirà una directory completa o una corrispondenza jolly. Sono lenti a prescindere, perché implicano la lettura di tutte le voci.

Ad esempio: supponiamo che tu abbia una directory con un milione di file chiamata "foo-000000.txt" tramite "foo-999999.txt" e un singolo "natalieportman.jpeg". Questi saranno veloci:

• ls -l foo-123456.txt
• open "foo-123456.txt"
• delete "foo-123456.txt"
• create "bar-000000.txt"
• open "natalieportman.jpeg"
• create "big_report.pdf"

questi falliranno, ma falliranno anche velocemente:

• ls -l bar-654321.txt
• open bar-654321.txt
• delete bar-654321.txt

questi saranno lenti, anche se restituiscono pochissimi risultati; anche quelli che falliscono, falliscono dopo aver scansionato tutte le voci:

• ls
• ls foo-1234*.txt
• delete *.jpeg
• move natalie* /home/emptydir/
• move *.tiff /home/seriousphotos/

Per prima cosa assicurati che la partizione ext3 abbia il dir_indexflag impostato.

sudo dumpe2fs /dev/sdaX |grep --color dir_index

Se manca, è possibile abilitarlo. Devi smontare il filesystem, quindi eseguire:

sudo tune2fs -O dir_index /dev/sdaX
sudo e2fsck -Df /dev/sdaX

Quindi montare il filesystem.

Non fa differenza finché non si raggiungono i 32.000 nomi ext3 per limite di directory. L'aggiornamento a ext4 può aggirare questo, così come gli altri vantaggi di ext4.

Più voci (file e directory) hai all'interno di una singola directory, più lento sarà l'accesso. Questo è vero per ogni filesystem, anche se alcuni sono peggiori di altri.

Una soluzione migliore è quella di creare una gerarchia di directory, come questa:

/users/a/aaron/
/users/a/andrew/
/users/b/betty/
/users/b/brian/

E se hai ancora bisogno di prestazioni migliori, puoi estendere più livelli:

/users/a/a/aaron
/users/a/n/anna
/users/a/n/andrew

La maggior parte dei sistemi di posta utilizza questo trucco con i propri file di coda di posta.

Inoltre, ho scoperto che con alcuni filesystem, avere avuto in passato molte voci in una directory rallenterà l'accesso a quella directory. Esegui una operazione ls -ldsulla directory per visualizzare la dimensione della voce di directory stessa. Se sono diversi MB o più e la directory è relativamente vuota, le prestazioni potrebbero essere scadenti. Rinominare la directory di mezzo, crearne una nuova con lo stesso nome, le stesse autorizzazioni e proprietà, quindi spostare il contenuto della vecchia directory nella nuova. Ho usato questo trucco molte volte per velocizzare significativamente i server di posta che erano stati rallentati dal filesystem.

Di recente ho sviluppato un server di archiviazione che doveva creare decine di milioni di file e centinaia di migliaia di directory. Ho confrontato XFS con ext4 e reiserfs. Ho scoperto che nel mio caso ext4 era leggermente più veloce di XFS. Reiser era interessante ma aveva dei limiti e quindi è stato abbandonato. Ho anche scoperto che ext4 era significativamente più veloce di ext3.

Quando si ottengono molti file per directory, il tempo di apertura dei file inizia a risentirne. L'I / O del file no. Anche il tempo di eliminazione dei file ne risente. Tuttavia, non è troppo lento su ext4. È abbastanza evidente sotto ext3 però. XFS ed ext4 sono abbastanza veloci su questo.

L'ultima volta che ho esaminato XFS e ho valutato i vantaggi e gli svantaggi dell'utilizzo di XFS su ext4, ho trovato segnalazioni di perdita di dati con XFS. Non sono sicuro che questo sia ancora un problema o se lo sia mai stato, ma mi ha reso abbastanza nervoso da evitare. Dato che ext4 è il file predefinito di Ubuntu, ha vinto facilmente su XFS.

Quindi, oltre al suggerimento di Tylerl che aiuterà dal punto di vista della gestione, ti suggerisco di aggiornare a ext4. Il limite per directory è 64000 voci con ext4

Un altro vantaggio è che il tempo di fsck è sostanzialmente più veloce. Non ho mai avuto problemi con la corruzione.

La cosa bella di ext4 è che puoi provare un volume ext3 su ext4 per provarlo. Vedi: Migrazione di un sistema live da filesystem ext3 a ext4

Una citazione da quel link:

Se non si è interessati dalle limitazioni di ext3 e non si è disposti a correre rischi, potrebbe non valerne la pena. D'altro canto, al completamento con esito positivo della procedura di migrazione, il sistema potrebbe essere più veloce, sperimentare controlli del file system ridotti e avere una maggiore affidabilità senza effetti negativi.

Quindi, vai avanti e provalo. Suggerisci prima di tutto il backup.

Sicuramente ci saranno alcune conseguenze nel fare questo. Il principale sarà IO lettura / scrittura. Oltre a ciò, è solo un modo molto spaventoso di gestire quel tipo di dati (su quella scala).

In passato ho usato XFS per aggirare i limiti di Ext3 con successo.

Il primo elenco dei contenuti dei file system richiederà un po 'di tempo prima che il sistema abbia letto tutte le informazioni sulla directory / sui file. Le operazioni supplementari saranno più veloci perché il kernel ha ora le informazioni memorizzate nella cache.

Ho visto gli amministratori eseguire 'find / somepath 2> & 1> / dev / null' in cron su base regolare per mantenere attiva la cache, migliorando le prestazioni.

Ho alcune domande e alcuni possibili risultati del collo di bottiglia.

Innanzitutto, si tratta di un sistema CentOS 5 o 6? Perché in 6 abbiamo un incredibile strumento chiamato blktrace, ideale per misurare l'impatto in questo tipo di situazioni.

https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/ch06s03.html

Possiamo quindi analizzare l'output con btt e ottenere dove si trovano i colli di bottiglia, l'applicazione, il filesystem, lo scheduler, l'archiviazione - a quale componente l'IO trascorre la maggior parte del tempo.

Ora, teoricamente arrivando alla tua domanda, aumenterà ovviamente il numero di inode e mentre continui a creare o accedere a file o directory nuovi o esistenti all'interno di directory, il tempo di accesso aumenterà. Il kernel deve attraversare una gerarchia di filesystem più ampia e quindi che senza dubbio è un sovraccarico.

Un altro punto da notare è che quando si aumenta il numero di directory, l'utilizzo della cache di inode e dentry aumenterà, il che significa consumo di più RAM. Questo rientra nella memoria slab, quindi se il tuo server sta esaurendo la memoria, questo è un altro punto di pensiero.

Parlando di un esempio del mondo reale, di recente ho visto che su un ext3 fs altamente annidato, la creazione di un subdir per la prima volta richiede circa 20 secondi mentre su ext4 richiede circa 4 secondi. Questo perché il modo in cui l'allocazione dei blocchi è strutturata in diversi filesystem. Se usi XFS o ext4 è inutile dire che otterrai un aumento delle prestazioni, per quanto minimo possa essere.

Quindi, se stai solo chiedendo quale sia la scelta giusta per il filesystem, ext3 è un po 'datato. Questo è tutto ciò che posso offrire senza ulteriori dati e benchmark.

Non è un'opzione su CentOS 5, e non sono sicuro di quanto sia un'opzione su CentOS 6, ma ho la sensazione che una soluzione basata su albero B o B *, ad esempio BTRFS, fornirebbe prestazioni costanti, se non significativamente migliori, in particolare scenario, se solo uno potesse affidargli i propri dati preziosi con una coscienza pulita (ancora non lo farei).

Ma se te lo puoi permettere, potresti provarlo.