{"id":95783,"date":"2020-10-03T13:42:02","date_gmt":"2020-10-03T11:42:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/nastrojka-yadra-linux-dlya-glusterfs"},"modified":"2020-10-03T13:42:02","modified_gmt":"2020-10-03T11:42:02","slug":"nastrojka-yadra-linux-dlya-glusterfs","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/nastrojka-yadra-linux-dlya-glusterfs","title":{"rendered":"Configurazione del kernel Linux per GlusterFS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

La traduzione dell'articolo \u00e8 stata preparata in vista dell'inizio del corso \u00abAmministratore Linux. Professionale\u00bb<\/a><\/noindex>.<\/i><\/b><\/p>\n

\"Configurazione<\/p>\n

Di tanto in tanto, sorgono domande sulle raccomandazioni di Gluster riguardo alla configurazione del kernel e se sia necessaria.<\/p>\n

Questa necessit\u00e0 si presenta raramente. Nella maggior parte dei carichi di lavoro, il kernel funziona molto bene. Anche se c'\u00e8 un altro lato. Storicamente, il kernel Linux tende a consumare molta memoria, se gli viene concessa tale possibilit\u00e0, anche per la memorizzazione nella cache come principale modo per migliorare le prestazioni.<\/a><\/noindex><\/p>\n

Nella maggior parte dei casi funziona ottimamente, ma con carichi elevati pu\u00f2 portare a problemi. <\/p>\n

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. <\/p>\n

Questo articolo \u00e8 il risultato di molti esperimenti sulla configurazione dei parametri, eseguiti in diverse situazioni. Grazie a questi parametri non solo \u00e8 migliorata la reattivit\u00e0 complessiva, ma ha anche stabilizzato notevolmente il funzionamento del cluster.<\/p>\n

Quando si tratta di configurazione della memoria, la prima cosa da fare \u00e8 guardare al sottosistema di memoria virtuale (VM, virtual memory), che ha un ampio numero di opzioni in grado di confonderti.<\/p>\n

vm.swappiness<\/h4>\n

\nParametro vm.swappiness<\/code> determina quanto il kernel utilizza lo swapping rispetto alla memoria RAM. Nel codice sorgente \u00e8 anche definito come \"tendency to steal mapped memory\" (tendenza a rubare memoria mappata). Un valore elevato di swappiness significa che il kernel sar\u00e0 pi\u00f9 incline a scaricare le pagine mappate. Un valore basso di swappiness significa il contrario: il kernel scaricher\u00e0 meno pagine dalla memoria. In altre parole, pi\u00f9 alto \u00e8 il valore vm.swappiness<\/code>, maggiore sar\u00e0 l'utilizzo dello swap da parte del sistema.<\/p>\n

Un elevato utilizzo dello swapping \u00e8 indesiderabile, poich\u00e9 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.<\/p>\n

Puoi leggere ulteriori dettagli qui \u2014 lwn.net\/Articles\/100978<\/a><\/noindex> <\/p>\n

Tuttavia, queste impostazioni devono essere applicate con cautela e solo dopo aver testato l'applicazione specifica. Per le applicazioni di streaming ad alta intensit\u00e0, questo parametro dovrebbe essere impostato su \"0\". Impostando su \"0\", la reattivit\u00e0 del sistema migliora.<\/p>\n

vm.vfs_cache_pressure<\/h4>\n

\nQuesto parametro controlla la memoria utilizzata dal kernel per la memorizzazione in cache degli oggetti delle directory e dei descrittori di indice (dentry e inode).<\/p>\n

Con il valore predefinito di 100, il kernel cercher\u00e0 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 \u00e8 \"0\", il kernel non liberer\u00e0 mai la cache dentry e inode a causa di una pressione di memoria, il che pu\u00f2 portare facilmente a un errore di out-of-memory. Aumentare vfs_cache_pressure oltre 100 porta il kernel a dare priorit\u00e0 allo scarico di dentry e inode.<\/p>\n

Quando si utilizza GlusterFS, molti utenti con grandi volumi di dati e numerosi piccoli file possono facilmente occupare una quantit\u00e0 significativa di memoria RAM sul server a causa della memorizzazione in cache di inode\/dentry, il che pu\u00f2 ridurre le prestazioni, poich\u00e9 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\u00f9 equa e migliorare la reattivit\u00e0 del kernel.<\/p>\n

vm.dirty_background_ratio e vm.dirty_ratio<\/h4>\n

\nIl primo parametro (vm.dirty_background_ratio<\/code>) definisce la percentuale di memoria con pagine sporche, oltre la quale deve iniziare il backup in background delle pagine sporche su disco. Finch\u00e9 questa percentuale non \u00e8 raggiunta, le pagine non vengono scritte su disco. Quando inizia il backup, esso viene eseguito in background, senza interrompere i processi in esecuzione. <\/p>\n

Il secondo parametro (vm.dirty_ratio<\/code>) determina la percentuale di memoria che pu\u00f2 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 \u00e8 consentito loro di continuare fino a quando l'operazione di input-output richiesta non \u00e8 effettivamente completata e i dati non sono scritti su disco. In situazioni di elevato carico di I\/O, questo causa problemi, poich\u00e9 non c'\u00e8 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\u00e0 del sistema e scarsa performance.<\/p>\n

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\u00f2 essere utile per i sistemi con grande quantit\u00e0 di memoria, per i quali \u00e8 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\u00e0 e l'interattivit\u00e0 complessiva.<\/p>\n

\u00ab1\u00bb > \/proc\/sys\/vm\/pagecache<\/h4>\n

\nIl page cache \u00e8 una cache in cui vengono memorizzati i dati di file e programmi eseguibili, cio\u00e8 sono pagine con il contenuto effettivo di file o dispositivi a blocchi. Questa cache \u00e8 utilizzata per ridurre il numero di letture da disco. Il valore \u00ab1\u00bb indica che per la cache viene utilizzato l'1% della RAM e ci saranno pi\u00f9 operazioni di lettura da disco che dalla RAM. Non \u00e8 necessario modificare questo parametro, ma se sei particolarmente attento al controllo della cache delle pagine, puoi approfittarne.<\/p>\n

\u00abdeadline\u00bb > \/sys\/block\/sdc\/queue\/scheduler<\/h4>\n

\nL'I\/O scheduler \u00e8 un componente del kernel Linux che gestisce le queue di lettura e scrittura. Teoricamente, per un RAID controller intelligente \u00e8 meglio utilizzare \u00abnoop\u00bb, poich\u00e9 Linux non conosce nulla della geometria fisica del disco, quindi \u00e8 pi\u00f9 efficiente permettere al controller, che conosce bene la geometria del disco, di elaborare le richieste il pi\u00f9 rapidamente possibile. Tuttavia, sembra che \u00abdeadline\u00bb migliori le performance. Maggiori dettagli sugli scheduler possono essere trovati nella documentazione del codice sorgente del kernel Linux: linux\/Documentation\/block\/*osched.txt<\/code>. Ho anche osservato un aumento della larghezza di banda di lettura durante combinazioni di operazioni (molte operazioni di scrittura).<\/p>\n

\u00ab256\u00bb > \/sys\/block\/sdc\/queue\/nr_requests<\/h4>\n

\nIl 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) \u00e8 maggiore rispetto a nr_requests dello scheduler di input-output, quindi lo scheduler ha poche possibilit\u00e0 di prioritizzare correttamente e eseguire la fusione delle richieste. Per gli scheduler deadline e CFQ \u00e8 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\u00f9 reattivo sotto carico elevato.<\/p>\n

echo \u00ab16\u00bb > \/proc\/sys\/vm\/page-cluster<\/h4>\n

\nIl parametro page-cluster gestisce il numero di pagine scritte nello swap in una sola volta. Nell'esempio sopra, il valore \u00e8 impostato a \u00ab16\u00bb 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\u00e0 quando la dimensione del stripe RAID \u00e8 di 64 KB.<\/p>\n

blockdev \u2014setra 4096 \/dev\/<<\/code>devname><\/code> (-sdb, hdc o dev_mapper)<\/h4>\n

\nLe 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\u00e0 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\u00f2 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.<\/p>\n

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\u00e0 cinque, poich\u00e9 un disco \u00e8 utilizzato per la parit\u00e0). Questi suggerimenti sono basati su supposizioni teoriche e raccolti da vari blog\/articoli di esperti di RAID.<\/p>\n

-> filesystem ext4, 5 dischi, stripe 64K, unit\u00e0 in blocchi da 4K\nmkfs -text4 -E stride=$((64\/4))\n-> xfs, 5 dischi, stripe 64K, unit\u00e0 in settori da 512 byte\nmkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))<\/code><\/pre>\n
\nPer file di grandi dimensioni, \u00e8 possibile considerare la possibilit\u00e0 di aumentare le dimensioni dei stripe sopra indicate.<\/p>\n
ATTENZIONE!<\/b> Tutto quanto descritto sopra \u00e8 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\u00e0 di migliorare la reattivit\u00e0 generale del sistema o se risolve problemi attuali.<\/p>\n
Materiali aggiuntivi:<\/h4>\n
<\/p>\n