La traduzione dell'articolo è stata preparata in vista dell'inizio del corso .
Di tanto in tanto, sorgono domande sulle raccomandazioni di Gluster riguardo alla configurazione del kernel e se sia necessaria.
Questa necessità si presenta raramente. Nella maggior parte dei carichi di lavoro, il kernel funziona molto bene. Anche se c'è un altro lato. Storicamente, il kernel Linux tende a consumare molta memoria, se gli viene concessa tale possibilità, anche per la memorizzazione nella cache come principale modo per migliorare le prestazioni.
Nella maggior parte dei casi funziona ottimamente, ma con carichi elevati può portare a problemi.
Abbiamo una grande esperienza con sistemi che consumano molta memoria, come CAD, EDA e simili, che iniziavano a rallentare con carichi elevati. E talvolta ci siamo imbattuti in problemi con Gluster. Osservando attentamente per diversi giorni la memoria utilizzata e il tempo di attesa dei dischi, abbiamo riscontrato sovraccarico, enormi iowait, errori del kernel (kernel oops), blocchi, ecc.
Questo articolo è il risultato di molti esperimenti sulla configurazione dei parametri, eseguiti in diverse situazioni. Grazie a questi parametri non solo è migliorata la reattività complessiva, ma ha anche stabilizzato notevolmente il funzionamento del cluster.
Quando si tratta di configurazione della memoria, la prima cosa da fare è guardare al sottosistema di memoria virtuale (VM, virtual memory), che ha un ampio numero di opzioni in grado di confonderti.
vm.swappiness
Parametro vm.swappiness determina quanto il kernel utilizza lo swapping rispetto alla memoria RAM. Nel codice sorgente è anche definito come "tendency to steal mapped memory" (tendenza a rubare memoria mappata). Un valore elevato di swappiness significa che il kernel sarà più incline a scaricare le pagine mappate. Un valore basso di swappiness significa il contrario: il kernel scaricherà meno pagine dalla memoria. In altre parole, più alto è il valore vm.swappiness, maggiore sarà l'utilizzo dello swap da parte del sistema.
Un elevato utilizzo dello swapping è indesiderabile, poiché enormi blocchi di dati vengono caricati e scaricati dalla memoria RAM. Molti sostengono che il valore di swappiness dovrebbe essere alto, ma per la mia esperienza, installarlo a "0" porta a un aumento delle prestazioni.
Puoi leggere ulteriori dettagli qui —
Tuttavia, queste impostazioni devono essere applicate con cautela e solo dopo aver testato l'applicazione specifica. Per le applicazioni di streaming ad alta intensità, questo parametro dovrebbe essere impostato su "0". Impostando su "0", la reattività del sistema migliora.
vm.vfs_cache_pressure
Questo parametro controlla la memoria utilizzata dal kernel per la memorizzazione in cache degli oggetti delle directory e dei descrittori di indice (dentry e inode).
Con il valore predefinito di 100, il kernel cercherà di liberare la cache dentry e inode "in modo equo" rispetto alla pagecache e alla swapcache. Ridurre vfs_cache_pressure porta il kernel a mantenere le cache dentry e inode. Quando il valore è "0", il kernel non libererà mai la cache dentry e inode a causa di una pressione di memoria, il che può portare facilmente a un errore di out-of-memory. Aumentare vfs_cache_pressure oltre 100 porta il kernel a dare priorità allo scarico di dentry e inode.
Quando si utilizza GlusterFS, molti utenti con grandi volumi di dati e numerosi piccoli file possono facilmente occupare una quantità significativa di memoria RAM sul server a causa della memorizzazione in cache di inode/dentry, il che può ridurre le prestazioni, poiché il kernel deve gestire le strutture dati su un sistema con 40 GB di memoria. Impostare questo parametro oltre 100 ha aiutato molti utenti a ottenere una memorizzazione in cache più equa e migliorare la reattività del kernel.
vm.dirty_background_ratio e vm.dirty_ratio
Il primo parametro (vm.dirty_background_ratio) definisce la percentuale di memoria con pagine sporche, oltre la quale deve iniziare il backup in background delle pagine sporche su disco. Finché questa percentuale non è raggiunta, le pagine non vengono scritte su disco. Quando inizia il backup, esso viene eseguito in background, senza interrompere i processi in esecuzione.
Il secondo parametro (vm.dirty_ratio) determina la percentuale di memoria che può essere occupata da pagine sporche prima dell'inizio di un flush forzato. Quando si raggiunge questa soglia, tutti i processi diventano sincroni (vengono bloccati) e non è consentito loro di continuare fino a quando l'operazione di input-output richiesta non è effettivamente completata e i dati non sono scritti su disco. In situazioni di elevato carico di I/O, questo causa problemi, poiché non c'è caching dei dati e tutti i processi che eseguono operazioni di input-output vengono bloccati in attesa di I/O. Questo porta a un gran numero di processi bloccati, elevato carico, instabilità del sistema e scarsa performance.
La riduzione dei valori di questi parametri porta a un maggior numero di scritture su disco e a una minore conservazione in RAM. Questo può essere utile per i sistemi con grande quantità di memoria, per i quali è normale scrivere su disco un cache di pagine di dimensioni tra 45 e 90 GB, il che provoca lunghi tempi di attesa per le applicazioni frontend, riducendo la reattività e l'interattività complessiva.
«1» > /proc/sys/vm/pagecache
Il page cache è una cache in cui vengono memorizzati i dati di file e programmi eseguibili, cioè sono pagine con il contenuto effettivo di file o dispositivi a blocchi. Questa cache è utilizzata per ridurre il numero di letture da disco. Il valore «1» indica che per la cache viene utilizzato l'1% della RAM e ci saranno più operazioni di lettura da disco che dalla RAM. Non è necessario modificare questo parametro, ma se sei particolarmente attento al controllo della cache delle pagine, puoi approfittarne.
«deadline» > /sys/block/sdc/queue/scheduler
L'I/O scheduler è un componente del kernel Linux che gestisce le queue di lettura e scrittura. Teoricamente, per un RAID controller intelligente è meglio utilizzare «noop», poiché Linux non conosce nulla della geometria fisica del disco, quindi è più efficiente permettere al controller, che conosce bene la geometria del disco, di elaborare le richieste il più rapidamente possibile. Tuttavia, sembra che «deadline» migliori le performance. Maggiori dettagli sugli scheduler possono essere trovati nella documentazione del codice sorgente del kernel Linux: linux/Documentation/block/*osched.txt. Ho anche osservato un aumento della larghezza di banda di lettura durante combinazioni di operazioni (molte operazioni di scrittura).
«256» > /sys/block/sdc/queue/nr_requests
Il numero di richieste di input-output memorizzate nel buffer prima che vengano passate allo scheduler. La dimensione della coda interna di alcuni controller (queue_depth) è maggiore rispetto a nr_requests dello scheduler di input-output, quindi lo scheduler ha poche possibilità di prioritizzare correttamente e eseguire la fusione delle richieste. Per gli scheduler deadline e CFQ è meglio che nr_requests sia il doppio della coda interna del controller. La fusione e la riordinazione delle richieste aiutano lo scheduler a essere più reattivo sotto carico elevato.
echo «16» > /proc/sys/vm/page-cluster
Il parametro page-cluster gestisce il numero di pagine scritte nello swap in una sola volta. Nell'esempio sopra, il valore è impostato a «16» in base alla dimensione del stripe (stripe size) RAID di 64 KB. Questo non ha senso con swappiness = 0, ma se hai impostato swappiness a 10 o 20, utilizzare questo valore ti aiuterà quando la dimensione del stripe RAID è di 64 KB.
blockdev --setra 4096 /dev/<devname> (-sdb, hdc o dev_mapper)
Le impostazioni predefinite dei dispositivi a blocchi per molti controller RAID portano spesso a prestazioni terribili. Aggiungendo l'opzione sopra indicata, si configura la lettura anticipata per 4096 * 512 byte di settori. Almeno per le operazioni in streaming, la velocità aumenta riempiendo la cache incorporata del disco attraverso la lettura anticipata durante il periodo in cui il kernel prepara l'input-output. I dati possono essere memorizzati nella cache che saranno richiesti alla successiva lettura. Una lettura anticipata troppo elevata può compromettere l'input-output casuale per file di grandi dimensioni, se utilizza potenzialmente il tempo utile del disco o carica dati al di fuori della cache.
Di seguito sono riportati alcuni ulteriori suggerimenti a livello di file system. Ma non sono ancora stati testati. Assicurati che il tuo file system conosca la dimensione del stripe e il numero di dischi nell'array. Ad esempio, che si tratta di un array raid5 con una dimensione del stripe di 64K composto da sei dischi (in realtà cinque, poiché un disco è utilizzato per la parità). Questi suggerimenti sono basati su supposizioni teoriche e raccolti da vari blog/articoli di esperti di RAID.
-> filesystem ext4, 5 dischi, stripe 64K, unità in blocchi da 4K
mkfs -text4 -E stride=$((64/4))
-> xfs, 5 dischi, stripe 64K, unità in settori da 512 byte
mkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))Per file di grandi dimensioni, è possibile considerare la possibilità di aumentare le dimensioni dei stripe sopra indicate.
ATTENZIONE! Tutto quanto descritto sopra è estremamente soggettivo per alcuni tipi di applicazioni. Questo articolo non garantisce alcun miglioramento senza un test preliminare delle rispettive applicazioni da parte dell'utente. Deve essere applicato solo in caso di necessità di migliorare la reattività generale del sistema o se risolve problemi attuali.
Materiali aggiuntivi:
Leggi di più
Fonte: habr.com
