La traduzione dell'articolo è stata preparata alla vigilia dell'inizio del corso .
Periodicamente, qua e là, sorgono domande sulle raccomandazioni di Gluster riguardo all'ottimizzazione del kernel e se ce n'è bisogno.
Una tale esigenza sorge raramente. Sulla maggior parte dei carichi di lavoro, il kernel funziona molto bene. Anche se c'è un aspetto negativo. Storicamente, il kernel Linux è stato disposto a consumare molta memoria se ne avesse l'opportunità, anche per la memorizzazione nella cache come modo principale per migliorare le prestazioni.
Nella maggior parte dei casi, funziona bene, ma sotto carico pesante può portare a problemi.
Abbiamo molta esperienza con sistemi ad alta intensità di memoria come CAD, EDA e simili, che hanno iniziato a rallentare sotto carico pesante. E a volte ci siamo imbattuti in problemi in Gluster. Dopo aver osservato attentamente l'utilizzo della memoria e la latenza del disco per molti giorni, abbiamo riscontrato il loro sovraccarico, enorme iowait, errori del kernel (kernel oops), blocchi, ecc.
Questo articolo è il risultato di molti esperimenti di messa a punto eseguiti in varie situazioni. Grazie a questi parametri, non solo la reattività complessiva è migliorata, ma anche il cluster si è notevolmente stabilizzato.
Quando si tratta di ottimizzare la memoria, la prima cosa da guardare è il sottosistema di memoria virtuale (VM, memoria virtuale), che ha un gran numero di opzioni che possono confonderti.
vm.swappiness
Parametro vm.swappiness determina quanto il kernel utilizza swap (swap, paging) rispetto alla RAM. È anche definito nel codice sorgente come "tendenza a rubare memoria mappata". Un'elevata swappiness significa che il kernel sarà più incline a scambiare le pagine mappate. Un valore di swappiness basso significa l'opposto: il kernel eseguirà meno pagine dalla memoria. In altre parole, maggiore è il valore vm.swappiness, più il sistema utilizzerà swap.
Un ampio uso dello scambio è indesiderabile, poiché enormi blocchi di dati vengono caricati e scaricati nella RAM. Molte persone sostengono che il valore di swapiness dovrebbe essere grande, ma nella mia esperienza, impostarlo su "0" porta a prestazioni migliori.
Puoi leggere di più qui -
Ma, ancora una volta, queste impostazioni dovrebbero essere applicate con cura e solo dopo aver testato una particolare applicazione. Per applicazioni di streaming molto caricate, questo parametro deve essere impostato su "0". Quando viene modificato in "0", la reattività del sistema migliora.
vm.vfs_cache_pressione
Questa impostazione controlla la memoria consumata dal kernel per la memorizzazione nella cache di directory e oggetti inode (dentry e inode).
Con un valore predefinito di 100, il kernel proverà a liberare le cache dentry e inode su una base "equa" per pagecache e swapcache. La diminuzione di vfs_cache_pressure fa sì che il kernel mantenga le cache dentry e inode. Quando il valore è "0", il kernel non scaricherà mai la cache dentry e inode a causa della pressione della memoria e questo può facilmente portare a un errore di memoria insufficiente. L'aumento di vfs_cache_pressure oltre 100 fa sì che il kernel dia priorità a dentry e inode flushing.
Quando si utilizza GlusterFS, molti utenti con grandi quantità di dati e molti file di piccole dimensioni possono facilmente utilizzare una quantità significativa di RAM sul server a causa della memorizzazione nella cache di inode/dentry, che può portare a un degrado delle prestazioni poiché il kernel deve elaborare le strutture di dati su un sistema con 40 GB di memoria . L'impostazione di questo valore sopra 100 ha aiutato molti utenti a ottenere una memorizzazione nella cache più equa e una migliore reattività del kernel.
vm.dirty_background_ratio e vm.dirty_ratio
Primo parametro (vm.dirty_background_ratio) determina la percentuale di memoria con pagine sporche, dopo aver raggiunto la quale è necessario iniziare a scaricare su disco le pagine sporche in background. Finché non viene raggiunta questa percentuale, nessuna pagina viene scaricata su disco. E quando inizia il ripristino, viene eseguito in background senza interrompere i processi in esecuzione.
Il secondo parametro (vm.dirty_ratio) definisce la percentuale di memoria che può essere occupata dalle pagine sporche prima che inizi il flash forzato. Una volta raggiunta questa soglia, tutti i processi diventano sincroni (bloccati) e non possono continuare fino a quando l'I/O richiesto non è effettivamente completato ei dati sono su disco. Con l'I/O pesante, ciò causa un problema perché non c'è memorizzazione nella cache dei dati e tutti i processi che eseguono l'I/O sono bloccati in attesa dell'I/O. Ciò porta a un gran numero di processi bloccati, carico elevato, instabilità del sistema e prestazioni scadenti.
Diminuendo queste impostazioni, i dati vengono scaricati su disco più frequentemente e non vengono archiviati nella RAM. Questo può aiutare i sistemi con molta memoria in cui è normale scaricare cache di pagine da 45-90 GB su disco, con conseguente enorme latenza per le applicazioni front-end, riducendo la reattività e l'interattività complessive.
"1" > /proc/sys/vm/pagecache
Una cache di pagina è una cache che memorizza i dati di file e programmi eseguibili, ovvero si tratta di pagine con il contenuto effettivo di file o dispositivi a blocchi. Questa cache viene utilizzata per ridurre il numero di letture del disco. Un valore di "1" significa che l'1% della RAM viene utilizzato per la cache e ci saranno più letture dal disco che dalla RAM. Non è necessario modificare questa impostazione, ma se sei paranoico riguardo al controllo della cache della pagina, puoi usarla.
"scadenza" > /sys/block/sdc/queue/scheduler
Lo scheduler I/O è un componente del kernel Linux che gestisce le code di lettura e scrittura. In teoria, è meglio usare "noop" per un controller RAID intelligente, perché Linux non sa nulla della geometria fisica del disco, quindi è più efficiente lasciare che il controller, che conosce bene la geometria del disco, elabori la richiesta il più velocemente possibile possibile. Ma sembra che la "scadenza" migliori le prestazioni. Puoi leggere ulteriori informazioni sugli scheduler nella documentazione del codice sorgente del kernel Linux: linux/Documentation/block/*osched.txt. E ho anche visto un aumento del throughput di lettura durante le operazioni miste (molte operazioni di scrittura).
"256" > /sys/block/sdc/queue/nr_requests
Il numero di richieste I/O nel buffer prima che vengano passate allo scheduler. La dimensione della coda interna di alcuni controller (queue_depth) è maggiore di nr_requests dello scheduler I/O, quindi lo scheduler I/O ha poche possibilità di assegnare correttamente la priorità e unire le richieste. Per gli scheduler con scadenza e CFQ, è meglio quando nr_requests è 2 volte la coda interna del controller. L'unione e il riordino delle richieste aiuta lo scheduler a essere più reattivo sotto carico pesante.
echo "16" > /proc/sys/vm/page-cluster
Il parametro page-cluster controlla il numero di pagine scritte contemporaneamente nello swap. Nell'esempio precedente, il valore è impostato su "16" in base alla dimensione della striscia RAID di 64 KB. Non ha senso con swappiness = 0, ma se imposti swappiness su 10 o 20, l'utilizzo di questo valore ti aiuterà quando la dimensione della striscia RAID è 64K.
blockdev --setra 4096 /dev/<nomedev> (-sdb, hdc o dev_mapper)
Le impostazioni predefinite del dispositivo a blocchi per molti controller RAID spesso si traducono in prestazioni pessime. L'aggiunta dell'opzione precedente imposta il read-ahead per settori da 4096 * 512 byte. Per lo meno, per le operazioni di streaming, la velocità viene aumentata riempiendo la cache del disco su chip con read-ahead durante il periodo utilizzato dal kernel per preparare l'I/O. La cache può contenere dati che verranno richiesti alla lettura successiva. Troppa prelettura può interrompere l'I/O casuale per file di grandi dimensioni se utilizza tempo su disco potenzialmente utile o carica dati al di fuori della cache.
Di seguito sono riportate alcune altre raccomandazioni a livello di file system. Ma non sono ancora stati testati. Assicurati che il tuo filesystem conosca la dimensione della striscia e il numero di dischi nell'array. Ad esempio, si tratta di un array raid5 stripe da 64K di sei dischi (in realtà cinque, poiché un disco viene utilizzato per la parità). Queste raccomandazioni sono basate su presupposti teorici e raccolte da vari blog/articoli di esperti RAID.
-> ext4 fs, 5 disks, 64K stripe, units in 4K blocks
mkfs -text4 -E stride=$((64/4))
-> xfs, 5 disks, 64K stripe, units in 512-byte sectors
mkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))Per file di grandi dimensioni, prendi in considerazione l'aumento delle dimensioni delle strisce sopra elencate.
ATTENZIONE! Quanto sopra descritto è altamente soggettivo per alcuni tipi di applicazioni. Questo articolo non garantisce alcun miglioramento senza un precedente test utente delle applicazioni correlate. Dovrebbe essere utilizzato solo se è necessario migliorare la reattività generale del sistema o se risolve i problemi attuali.
Materiali aggiuntivi:
Leggi di più
Fonte: habr.com