Prima di modificare i parametri di XFS è necessario capire perchè i suoi parametri predefiniti possono causare problemi alle prestazioni. Per fare questo è necessario comprendere il comportamento dell'applicazione interessata e le reazioni del file system alle suddette operazioni.
Le problematiche relative alle prestazioni che si possono correggere o ridurre tramite un processo di ottimizzazione, vengono generalmente causate da una frammentazione del file o da un conflitto di risorse nel file system. Per risolvere questi problemi sono disponibili diversi metodi, e in alcuni casi la correzione del problema richiderà la modifica dell'applicazione e non della configurazione del file system.
Se non avete eseguito prima questo processo è consigliato consultare il Red Hat support engineer.
Ottimizzazione di numerosi file
XFS impone un limite arbitrario sul numero di file archiviabili su un file system. In generale questo limite è sufficientemente elevato da non essere mai superato. Se credete che il limite predefinito non sia sufficiente, aumentate la percentuale di spazio del file system per gli inode tramite il comando mkfs.xfs. Se raggiungete il limite del file dopo la creazione del file system (generalmente indicato da errori ENOSPC durante il tentativo di creare un file o directory anche se lo spazio è disponibile), è possibile modificare il limite con il comando xfs_growfs.
Ottimizzazione di numerosi file in una directory
Per l'intero ciclo di vita di un file system la dimensione di un blocco della directory è fissa e può essere modificata solo durante la formattazione iniziale con il comando mkfs. La dimensione minima del blocco della directory corrisponde a quella del blocco del file system, che per impostazione predefinita è su MAX (4 KB). In generale non vi è alcun motivo per ridurre la dimensione del blocco della directory.
Poichè le struttura della directory si basa su b-tree, la modifica della dimensione del blocco può cambiare la quantità delle informazioni della directory ripristinabili o modificabili per I/O fisico. Più grande è la directory, maggiore è la quantità di I/O necessaria ad una operazione per la dimensione di un dato blocco.
Tuttavia se utilizzate dimensioni del blocco della directory più grandi, ogni operazione di modifica può utilizzare più CPU rispetto alla stessa operazione su un file system con una dimensione del blocco più piccola. Ciò significa che per directory più piccole, dimensioni del blocco più grandi possono ridurre le prestazioni del processo di modifica. Quando una directory raggiunge una dimensione dove l'I/O risulta essere il fattore che limitale prestazioni, le directory con un blocco più grande hanno migliori prestazioni.
La configurazione predefinita che comprende un file system con blocco di dimensioni di 4 KB e una directory con un blocco di 4 KB, è quella più idonea per directory con un numero di voci di 1-2 milioni e con lunghezza del nome pari a 20-40 byte per voce. Se un file system ha bisogno di un numero maggiore di voci, le directory con un blocco più grande presentano migliori prestazioni - una dimensione del blocco di 16 KB è più idoneo per file system con un numero di voci pari a 1-10 milioni, mentre un blocco di 64 KB è il più idoneo per file system con un numero di voci maggiore a 10 milioni.
Se il carico di lavoro utilizza le ricerche randomiche della directory più delle modifiche (cioè le letture delle directory risultano essere più comuni o importanti rispetto ai processi di scrittura), i limiti sopra indicati per l'aumento della dimensione del blocco saranno approssimativamente inferiori.
Ottimizzazione tramite processi simultanei
Diversamente da altri file system, XFS è in grado di assegnare e deallocare simultaneamente se tali operazioni si verificano su oggetti non condivisi. È possibile eseguire simultaneamente le suddette operazioni nei confronti delle estensioni se i gruppi risultano essere diversi. In modo simile i processi di assegnazione/deallocazione di inode si possono verificare se tali operazioni interessano gruppi diversi.
Il numero dei gruppi di assegnazione è importante quando si utilizzano macchine con un conteggio CPU elevato e applicazioni multi-threaded che tentano di eseguire operazioni simultanee. Se esistono solo quattro gruppi di assegnazione, operazioni parallele e continuate di metadati interesseranno solo le quattro CPU (il limite fornito dal sistema). Per file system piccoli, assicuratevi che il numero di gruppi di assegnazione sia supportato dal limite di operazioni simultanee fornito dal sistema. Per file system grandi (decine di terabyte o maggiori) le opzioni di formattazione predefinite generalmente sono in grado di creare un numero di gruppi sufficiente per non limitare questo processo.
Le applicazioni devono essere a conoscenza dei punti di contesa per poter eseguire operazioni in parallelo, capacità ereditata nella struttura del file system XFS. Non è possibile modificare simultaneamente una directory, per questo motivo le applicazioni in grado di creare e rimuovere un numero molto grande di file, non dovrebbero eseguire l'archiviazione in una singola directory. Ogni directory creata viene posizionata in un gruppo di assegnazione diverso, quindi tecniche come il file hashing su directory multiple forniscono un percorso di archiviazione più scalabile rispetto all'uso di una directory singola molto grande.
Ottimizzazione delle applicazioni che utilizzano attributi estesi
Se lo spazio è disponibile sull'inode, XFS è in grado di archiviare attributi direttamente al suo interno. Se l'attributo è idoneo per l'inode, esso potrà essere ripristinato e modificato senza alcun I/O aggiuntivo per il recupero di blocchi separati dell'attributo. Le prestazioni per attributi out-of-line (attributi non presenti all'interno dell'inode in questione) saranno più basse rispetto a quelle degli attributi in-line (presenti all'interno dell'inode in questione).
Per la dimensione predefinita dell'inode pari a 256 byte, 100 byte di spazio circa è disponibile in base al numero di puntatori dell'estensione dei dati archiviati nell'inode. La dimensione predefinita dell'inode è utile per l'archiviazione di un numero ridotto di piccoli attributi.
Aumentando la dimensione dell'inode al momento di mkfs è possibile aumentare lo spazio disponibile per l'archiviazione degli attributi "in-line". Un inode di 512 byte aumenta lo spazio disponibile per gli attributi a circa 350 byte, un inode di 2 KB avrà circa 1900 byte di spazio disponibile.
Tuttavia è presente un limite sulla dimensione dei singoli attributi archiviabili in-line - infatti è presente un limite massimo di 254 byte sia per l'attributo name che per value (attributi name e value di 254 byte verranno classificati come in-line). Se questi limiti vengono superati, gli attributi verranno forzati fuori (out-of-line) anche se è disponibile spazio sufficiente per archiviare tutti gli attributi nell'inode.
Ottimizzazione per modifiche sostenute dei metadati
La dimensione del log è il fattore principale per determinare il livello di modifica sostenuto dai metadati. Il dispositivo di log è circolare, quindi prima di poter sovrascrivere la coda tutte le modifiche presenti nel log devono essere salvate nelle posizioni reali sul disco. Tale operazione può richiedere tentativi ripetuti di riscrittura di metadati corrotti. La configurazione predefinita modifica la dimensione del log in base alla dimensione generale del file system, quindi in molti casi la dimensione non avrà bisogno di alcuna ottimizzazione.
Se implementate un dispositivo di log piccolo si verificheranno processi di writeback frequenti dei metadati - il log avrà la necessità di cancellare le voci più vecchie per liberare spazio, così facendo i metadati modificati verranno continuamente scritti sul disco causando una riduzione nelle prestazioni delle operazioni.
Aumentando la dimensione del log verrà aumentato il periodo di tempo tra gli eventi di tail pushing. Ciò permette una migliore aggregazione dei metadati "sporchi" e migliori pattern di writeback dei metadati insieme ad un numero minore di writeback dei metadati modificati più frequentemente. Uno degli aspetti negativi è rappresentato dai log più grandi i quali richiedono una memoria maggiore per monitorare tutte le modifiche ancora presenti della memoria.
Se siete in possesso di una macchina con una memoria limitata i log più grandi non rappresentano un fattore positivo, questo poichè le limitazioni della memoria causeranno un writeback dei metadati, rimuovendo così tutti i benefici dovuti alla presenza di un log molto grande. In questi casi, spesso i log più piccoli possono fornire una migliore prestazione poichè il writeback dei metadati del log con uno spazio ridotto è molto più efficiente rispetto al writeback eseguito in base al memory reclamation.
È sempre consigliato cercare di allineare il log con il segmento sottostante del dispositivo che contiene il file system. Su dispositivi MD e DM, mkfs esegue questa operazione per impostazione predefinita, ma per hardware RAID sarà necessario specificarla. Una impostazione corretta impedirà ad un log I/O di generare un I/O non allineato, quindi operazioni read-modify-write al momento della scrittura delle modifiche sul disco.
Le operazioni di log possono essere ulteriormente migliorate modificando le opzioni di montaggio. Aumentando la dimensione dei buffer log in-memoria (logbsize), aumenterete la velocità con la quale le modifiche verranno scritte sul log. La dimensione del buffer log predefinita è MAX (32 KB, unità segmento di log), con dimensione massima di 256 KB. In generale, un valore più grande corrisponderà a prestazioni più veloci. Tuttavia con carichi di lavoro fsync molto grandi, buffer log piccoli possono essere più veloci rispetto a buffer più grandi con un allineamento maggiore dell'unità del segmento.
Anche l'opzione di montaggio delaylog migliora le prestazioni per le modifiche sostenute dei metadati tramite la riduzione del numero di modifiche per il log. Per fare questo le modifiche vengono raggruppate nella memoria prima di essere salvate sul log: i metadati modificati con molta frequenza vengono scritti periodicamente sul log e non ad ogni verifica. Questa opzione migliora l'uso della memoria durante il monitoraggio dei metadati corrotti, ed aumenta il numero di possibili operazioni perse in presenza di un crash, ma al tempo stesso migliora la velocità di modifica dei metadati e la scalabilità. L'uso di questa opzione non riduce l'integrità dei dati o metadati quando si utilizzano fsync, fdatasync o sync per la loro scrittura sul disco.
Red Hat Summit