{"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":"Impostazione 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

\"Impostazione<\/p>\n

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

Tale necessit\u00e0 si presenta raramente. Nella maggior parte dei casi, il kernel funziona molto bene. Tuttavia, c'\u00e8 un'altra faccia della medaglia. Storicamente, il kernel di Linux tende a consumare molta memoria se gli viene data l'opportunit\u00e0, incluso l'uso della cache come principale modalit\u00e0 per migliorare le prestazioni.<\/a><\/noindex><\/p>\n

In molti casi, questo funziona alla grande, ma sotto carichi elevati potrebbe causare problemi. <\/p>\n

Abbiamo una vasta esperienza con sistemi che consumano molta memoria, come CAD, EDA e simili, che hanno iniziato a rallentare sotto carichi pesanti. A volte abbiamo riscontrato problemi con Gluster. Dopo aver monitorato attentamente per diversi giorni la memoria utilizzata e i tempi di attesa dei dischi, abbiamo registrato sovraccarichi, enormi iowait, errori del kernel (kernel oops), blocchi, ecc. <\/p>\n

Questo articolo \u00e8 il risultato di molti esperimenti sull'ottimizzazione delle impostazioni, effettuati in diverse situazioni. Grazie a queste impostazioni, non solo \u00e8 migliorata la reattivit\u00e0 complessiva, ma \u00e8 anche notevolmente stabilizzata l'attivit\u00e0 del cluster.<\/p>\n

Quando si tratta di ottimizzare la memoria, \u00e8 fondamentale esaminare prima il sistema di memoria virtuale (VM, virtual memory), che offre un ampio numero di opzioni che possono confondervi.<\/p>\n

vm.swappiness<\/h4>\n

\nCaratteristica vm.swappiness<\/code> definisce quanto il kernel utilizza lo swap rispetto alla memoria RAM. Nel codice sorgente \u00e8 anche definito come \"tendency to steal mapped memory\". 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 le pagine dalla memoria. In altre parole, pi\u00f9 alto \u00e8 il valore vm.swappiness<\/code>, maggiore sar\u00e0 l'uso dello swap da parte del sistema.<\/p>\n

Un uso intenso dello swapping \u00e8 sconsigliato, poich\u00e9 grandi blocchi di dati vengono caricati e scaricati nella memoria. Molti sostengono che il valore di swapiness debba essere alto, ma nella mia esperienza, l'impostazione a '0' porta a un miglioramento delle prestazioni.<\/p>\n

Puoi leggere di pi\u00f9 qui \u2014 lwn.net\/Articles\/100978<\/a><\/noindex> <\/p>\n

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

vm.vfs_cache_pressure<\/h4>\n

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

Con un valore predefinito di 100, il kernel cercher\u00e0 di liberare la cache dentry e inode in modo \"equo\" rispetto a pagecache e swapcache. Ridurre vfs_cache_pressure far\u00e0 s\u00ec che il kernel mantenga le cache dentry e inode. Quando il valore \u00e8 \"0\", il kernel non pulir\u00e0 mai la cache dentry e inode a causa della mancanza di memoria (memory pressure), e questo pu\u00f2 facilmente portare a un errore di out-of-memory. Aumentare vfs_cache_pressure oltre 100 porter\u00e0 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 molti piccoli file possono facilmente utilizzare una quantit\u00e0 significativa di memoria sul server a causa della cache di inode\/dentry, il che pu\u00f2 portare a una riduzione delle prestazioni, poich\u00e9 il kernel deve elaborare le strutture dati in un sistema con 40 GB di memoria. Impostare questo parametro a oltre 100 ha aiutato molti utenti a ottenere una cache pi\u00f9 equa e a 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>) determina la percentuale di memoria con pagine sporche, al raggiungimento della quale \u00e8 necessario avviare un flush in background delle pagine sporche su disco. Finch\u00e9 questa percentuale non viene raggiunta, le pagine non vengono scaricate su disco. E quando il flush inizia, avviene in background, senza interrompere i processi in esecuzione. <\/p>\n

Il secondo parametro (vm.dirty_ratio<\/code>) definisce la percentuale di memoria che pu\u00f2 essere occupata da pagine sporche prima dell'inizio di un flush forzato. Al raggiungimento di questa soglia, tutti i processi diventano sincroni (bloccati) e non possono continuare a funzionare finch\u00e9 l'operazione di input\/output richiesta non \u00e8 effettivamente completata e i dati non sono scritti su disco. In caso di un carico elevato di operazioni di input\/output, ci\u00f2 provoca un problema, poich\u00e9 la memorizzazione nella cache dei dati non \u00e8 disponibile e tutti i processi che eseguono input\/output vengono bloccati in attesa di operazioni di input\/output. Questo porta a un numero elevato di processi bloccati, alto carico, instabilit\u00e0 del sistema e scarse prestazioni.<\/p>\n

Ridurre i valori di questi parametri fa s\u00ec che i dati vengano scritti su disco pi\u00f9 frequentemente e non venga mantenuta la memoria RAM. Questo pu\u00f2 essere utile per sistemi con molta memoria, dove \u00e8 normale scrivere su disco la cache delle pagine da 45 a 90 GB, il che porta a tempi di attesa elevati per le applicazioni frontend, diminuendo la reattivit\u00e0 e l'interattivit\u00e0 complessive.<\/p>\n

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

\nLa cache delle pagine (page cache) \u00e8 un'area di memoria in cui vengono conservati i dati dei file e dei programmi eseguibili, ovvero sono le pagine con il contenuto reale dei file o dei dispositivi di blocco. Questa cache viene utilizzata per ridurre il numero di letture dal disco. Il valore \u00ab1\u00bb indica che per la cache viene utilizzato l'1% della RAM e ci saranno pi\u00f9 operazioni di lettura dal disco rispetto alla RAM. Non \u00e8 necessario modificare questo parametro, ma se si \u00e8 particolarmente attenti al controllo della cache delle pagine, si pu\u00f2 usufruire di questa opzione.<\/p>\n

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

\nLo scheduler I\/O \u00e8 un componente del kernel Linux che gestisce le code di lettura e scrittura. Teoricamente, per un RAID controller intelligente \u00e8 meglio utilizzare \"noop\", perch\u00e9 Linux non conosce la geometria fisica del disco, quindi \u00e8 pi\u00f9 efficiente lasciare che il controller, che conosce bene la geometria del disco, gestisca le richieste il pi\u00f9 rapidamente possibile. Tuttavia, sembra che \"deadline\" aumenti le prestazioni. Puoi leggere di pi\u00f9 sugli scheduler 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 operazioni miste (molte operazioni di scrittura).<\/p>\n

\"256\" > \/sys\/block\/sdc\/queue\/nr_requests<\/h4>\n

\nIl numero di richieste di input\/output che vengono messe in buffer prima di essere inviate allo schedule. La dimensione della coda interna di alcuni controller (queue_depth) \u00e8 maggiore della nr_requests dello scheduler di I\/O, quindi lo scheduler ha poche possibilit\u00e0 di dare priorit\u00e0 correttamente e di eseguire la fusione delle richieste. Per gli scheduler deadline e CFQ \u00e8 preferibile che nr_requests sia il doppio della coda interna del controller. La fusione e la riordino delle richieste aiutano lo scheduler a essere pi\u00f9 reattivo sotto carico.<\/p>\n

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

\nIl parametro page-cluster gestisce il numero di pagine che vengono scritte nello swap in un colpo solo. Nell'esempio sopra, il valore \u00e8 impostato a \u00ab16\u00bb in base alla dimensione del stripe (stripe size) RAID di 64 KB. Non ha senso con swappiness = 0, ma se hai impostato swappiness a 10 o 20, l'utilizzo di 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 di archiviazione per molti controller RAID spesso portano a prestazioni disastrose. Aggiungendo l'opzione sopra indicata, si configura la lettura anticipata per settori di 4096 * 512 byte. Almeno per le operazioni di streaming, si aumenta la velocit\u00e0 riempiendo la cache integrata del disco attraverso la lettura anticipata nel periodo in cui il kernel \u00e8 impegnato a preparare le operazioni di input\/output. I dati possono essere memorizzati nella cache e richiesti alla lettura successiva. Una lettura anticipata eccessiva pu\u00f2 compromettere l'input\/output casuale per file di grandi dimensioni, se sfrutta il tempo utile del disco o carica dati oltre la cache.<\/p>\n

Di seguito sono riportati ulteriori suggerimenti a livello di file system. Tuttavia, non sono stati ancora testati. Assicurati che il tuo file system conosca la dimensione dello stripe e il numero di dischi nell'array. Ad esempio, che si tratta di un array raid5 con dimensione dello stripe di 64K composto da sei dischi (effettivamente da cinque, poich\u00e9 un disco \u00e8 utilizzato per la parit\u00e0). Questi consigli sono basati su ipotesi teoriche e raccolti da vari blog\/articoli di esperti in RAID.<\/p>\n

-> ext4 fs, 5 dischi, 64K stripe, unit\u00e0 in blocchi da 4K\nmkfs -text4 -E stride=$((64\/4))\n-> xfs, 5 dischi, 64K stripe, 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, potresti considerare di aumentare le dimensioni degli stripe sopra indicati.<\/p>\n
ATTENZIONE!<\/b> Tutto ci\u00f2 che \u00e8 stato descritto sopra \u00e8 estremamente soggettivo per alcuni tipi di applicazioni. Questo articolo non garantisce alcun miglioramento senza un test preliminare delle relative applicazioni da parte dell'utente. Dovrebbe essere applicato solo se necessario per migliorare la reattivit\u00e0 complessiva del sistema o, se risolve problemi attuali.<\/p>\n
Materiale aggiuntivo:<\/h4>\n
<\/p>\n