Procedure consigliate per la cache del file system Linux per Azure NetApp Files

Articolo
09/05/2024

Questo articolo illustra le procedure consigliate per la cache del file system per Azure NetApp Files.

Parametri ottimizzabili della cache del file system

È necessario comprendere i fattori seguenti relativi ai parametri ottimizzabili della cache del file system:

Lo scaricamento di un buffer dirty lascia i dati in uno stato pulito utilizzabile per letture future fino a quando un utilizzo elevato di memoria non comporta la rimozione.
Esistono tre trigger per un'operazione di scaricamento asincrona:
- In base al tempo: quando un buffer raggiunge la durata definita da questo parametro ottimizzabile, deve essere contrassegnato per la pulizia (ovvero scaricamento o scrittura nella risorsa di archiviazione).
- Utilizzo elevato di memoria: per informazioni dettagliate, vedere vm.dirty_ratio | vm.dirty_bytes.
- Chiusura: quando un handle di file viene chiuso, tutti i buffer dirty vengono scaricati in modo asincrono nella risorsa di archiviazione.

Questi fattori sono controllati da quattro parametri ottimizzabili. Ogni parametro ottimizzabile può essere ottimizzato in modo dinamico e persistente usando tuned o sysctl nel file /etc/sysctl.conf. L'ottimizzazione di queste variabili migliora le prestazioni delle applicazioni.

Nota

Le informazioni descritte in questo articolo sono state individuate durante gli esercizi di convalida SAS GRID e SAS Viya. Pertanto, i parametri ottimizzabili si basano sulle lezioni apprese dagli esercizi di convalida. Molte applicazioni traggono vantaggio dall'ottimizzazione di questi parametri.

`vm.dirty_ratio | vm.dirty_bytes`

Questi due parametri ottimizzabili definiscono la quantità di RAM resa utilizzabile per i dati modificati ma non ancora scritti in una risorsa di archiviazione stabile. Qualunque sia il parametro ottimizzabile impostato, l'altro parametro ottimizzabile viene impostato automaticamente su zero; RedHat consiglia di non impostare manualmente uno dei due parametri ottimizzabili su zero. L'opzione vm.dirty_ratio (l'opzione predefinita delle due) è impostata da Redhat sul 20% o sul 30% della memoria fisica a seconda del sistema operativo, che è una quantità significativa considerando il footprint della memoria dei sistemi moderni. È consigliabile prendere in considerazione l'impostazione di vm.dirty_bytes invece di vm.dirty_ratio per un'esperienza più coerente indipendentemente dalle dimensioni della memoria. Ad esempio, un lavoro in corso con SAS GRID ha determinato che 30 MiB è un'impostazione appropriata per ottenere le migliori prestazioni complessive con carichi di lavoro misti.

`vm.dirty_background_ratio | vm.dirty_background_bytes`

Questi parametri ottimizzabili definiscono il punto di partenza in cui il meccanismo di writeback di Linux inizia a scaricare blocchi dirty in una risorsa di archiviazione stabile. L'impostazione predefinita di Redhat è il 10% della memoria fisica, che, in un sistema di memoria di grandi dimensioni, rappresenta una quantità significativa di dati per avviare lo scaricamento. Con SAS GRID come esempio, storicamente la raccomandazione era di impostare vm.dirty_background su 1/5 delle dimensioni di vm.dirty_ratio o vm.dirty_bytes. Considerando l'aggressività dell'impostazione di vm.dirty_bytes per SAS GRID, qui non viene impostato alcun valore specifico.

`vm.dirty_expire_centisecs`

Questo parametro ottimizzabile definisce la durata di un buffer dirty prima che sia necessario contrassegnarlo per la scrittura asincrona. Si prenda ad esempio il carico di lavoro CAS di SAS Viya. Un carico di lavoro temporaneo con scrittura dominante ha rilevato che l'impostazione di questo valore su 300 centisecondi (3 secondi) è ottimale, con 3000 centisecondi (30 secondi) come impostazione predefinita.

SAS Viya condivide i dati CAS in più blocchi di piccole dimensioni di pochi megabyte ciascuno. Anziché chiudere questi handle di file dopo aver scritto i dati in ogni partizione, gli handle vengono lasciati aperti e i buffer all'interno vengono mappati alla memoria dall'applicazione. Senza una chiusura, non c'è scaricamento fino al passaggio di un utilizzo elevato di memoria o di 30 secondi. L'attesa di un utilizzo elevato di memoria è risultata non ottimale così come l'attesa della scadenza di un timer lungo. A differenza di SAS GRID, che ha cercato la migliore velocità effettiva complessiva, SAS Viya ha cercato di ottimizzare la larghezza di banda di scrittura.

`vm.dirty_writeback_centisecs`

Il thread di scaricamento del kernel è responsabile dello scaricamento asincrono dei buffer dirty tra ogni sospensione del thread di scaricamento. Questo parametro ottimizzabile definisce la durata della sospensione tra gli scaricamenti. Considerando il valore vm.dirty_expire_centisecs di 3 secondi usato da SAS Viya, SAS ha impostato questo parametro ottimizzabile su 100 centisecondi (1 secondo) anziché sul valore predefinito di 500 centisecondi (5 secondi) per trovare le migliori prestazioni complessive.

Impatto di una cache del file system non ottimizzata

Se si considerano i parametri ottimizzabili predefiniti della memoria virtuale e la quantità di RAM nei sistemi moderni, il writeback rallenta potenzialmente altre operazioni associate all'archiviazione dal punto di vista del client specifico che gestisce questo carico di lavoro misto. I sintomi seguenti possono essere previsti da un computer Linux non ottimizzato con intensa attività di scrittura e con carico di cache.

Gli elenchi di directory ls richiedono tempi talmente lunghi da sembrare che non rispondono.
La velocità effettiva di lettura del file system diminuisce significativamente rispetto alla velocità effettiva di scrittura.
nfsiostat riporta latenze di scrittura in secondi o più.

Questo comportamento può verificarsi solo nel computer Linux che esegue il carico di lavoro misto con intensa attività di scrittura. Inoltre, l'esperienza risulta ridotta rispetto a tutti i volumi NFS montati su un singolo endpoint di archiviazione. Se i montaggi provengono da due o più endpoint, solo i volumi che condividono un endpoint presentano questo comportamento.

È stato dimostrato che l'impostazione dei parametri della cache del file system come descritto in questa sezione risolve il problema.

Monitoraggio della memoria virtuale

Per comprendere cosa accade con la memoria virtuale e il writeback, prendere in considerazione il frammento di codice e l'output seguenti. Dirty rappresenta la quantità di memoria dirty nel sistema, mentre writeback rappresenta la quantità di memoria scritta attivamente nella risorsa di archiviazione.

# while true; do echo "###" ;date ; egrep "^Cached:|^Dirty:|^Writeback:|file" /proc/meminfo; sleep 5; done`

L'output seguente proviene da un esperimento in cui il rapporto vm.dirty_ratio e il rapporto vm.dirty_background sono stati impostati rispettivamente sul 2% e sull'1% della memoria fisica. In questo caso, lo scaricamento è iniziato a 3,8 GiB, l'1% del sistema di memoria da 384 GiB. Il writeback è simile alla velocità effettiva di scrittura in NFS.

Cons
Dirty:                                    1174836 kB
Writeback:                         4 kB
###
Dirty:                                    3319540 kB
Writeback:                         4 kB
###
Dirty:                                    3902916 kB        <-- Writes to stable storage begins here
Writeback:                         72232 kB   
###
Dirty:                                    3131480 kB
Writeback:                         1298772 kB

Condividi tramite