Red Hat Summit2.9.3. Risoluzione problematiche relative alle prestazioni di GFS2 con il GFS2 Lock Dump
Se si verifica un deterioramento delle prestazioni del cluster a causa di un uso inefficiente del caching del GFS2, potrete notare un aumento dei tempi di attesa I/O. A tale scopo usate le informazioni presenti nel lock dump di GFS2 per determinare la causa del problema.
Questa sezione fornisce solo una breve descrizione del lock dump di GFS2. Per informazioni più dettagliate consultare Appendice C, Tracepoint GFS2 e debugfs glock File.
Le informazioni presenti nel lock dump del GFS2 sono disponibili nel file
debugfs attraverso il seguente nome del percorso, assumendo che debugfs sia stato montato su /sys/kernel/debug/:
/sys/kernel/debug/gfs2/fsname/glocks
/sys/kernel/debug/gfs2/fsname/glocks
Il contenuto è una serie di linee. Ogni linea che inizia con G: rappresenta un glock, e linee seguenti, rappresentano le informazioni relative al glock che le precede sul file.
Il modo migliore per usare il file
debugfs è quello di utilizzare il comando cat per avere una copia del contenuto completo del file (potrebbe richidere molto tempo se siete in possesso di una quantità di RAM molto grande ed un numero elevato di inode presenti in cache) se l'aplicazione presenta qualche problema, consultando le informazioni presenti in un secondo momento.
Nota
Potrebbe essere utile creare due copie del file
debugfs una dopo qualche secondo o minuto dalla precedente. Confrontando le informazioni dell'holder nelle due tracce relative allo stesso numero di glock sarete in grado di verificare se il carico di lavoro prosegue senza alcun problema (lentamente) o se si è fermato (in questo caso siamo in presenza di un bug da riportare al supporto di Red Hat immediatamente).
Le linee nel file
debugfs che iniziano con H: (holder 'detentori') rappresentano le richieste del blocco conferite o in attesa di essere assegnate. Il campo dei flag sulla linea f: mostra quale: Il flag 'W' si riferisce alla richiesta in attesa, 'H' invece si riferisce alla richiesta assegnata. I glock che possiedono un numero elevato di richieste d'attesa nella maggior parte dei casi sono quelli con maggiore contesa.
Tabella 2.1, «Flag di glock» mostra il significato dei diversi flag di glock mentre Tabella 2.2, «Flag holder di glock» mostra il significato dei diversi flag degli holder di glock nell'ordine presente nei dump di glock.
| Flag | Nome | Significato |
|---|---|---|
| b | Blocco | Valido se impostato un flag locked, indica che l'operazione richiesta dal DLM potrebbe eseguire un blocco. Questo flag viene annullato per operazioni di declassamento e per lock "try". Lo scopo di questo flag è quello di permettere la raccolta di statistiche sul tempo di risposta DLM, indipendentemente dal tempo necessario per altri nodi di eseguire operazioni di demote dei lock. |
| d | Pending demote | Una richiesta di retrocessione (remota) rinviata |
| D | Demote (retrocessione) | Una richiesta di retrocessione (locale o remota) |
| f | Log flush | È necessario eseguire il commit del log prima di rilasciare questo glock |
| F | Frozen | Le repliche dei nodi remoti verranno ignorate - il recupero è in corso. Questo flag non si riferisce al freeze del file system, il quale utilizza un meccanismo diverso, ma viene usato solo per operazioni di ripristino. |
| i | Invalidate in progress | La rimozione in questo glock della convilida delle pagine è in corso |
| I | Initial | Impostato quando il blocco DLM è associato con questo glock |
| l | Locked | Il glock è in procinto di cambiare stato |
| L | LRU | Impostato quando glock è sull'elenco LRU |
| o | Oggetto | Impostato quando glock è associato con un oggetto (cioè un inode per il tipo 2 di glock, e un gruppo di risorse per il tipo 3 di glock) |
| p | Demote in progress | Glock è in procinto a rispondere ad una richiesta di retrocessione |
| q | In coda | Impostato quando un holder è in coda per un glock ed è rimosso quando un glock è occupato, quando altri holder non sono disponibili. Usato come parte dell'algoritmo per il calcolo dell'intervallo minimo per un glock. |
| r | Reply pending | La risposta ricevuta da un nodo remoto è in attesa di processazione |
| y | Dirty | È necessario azzerare i dati sul disco prima di rilasciare questo glock |
| Flag | Nome | Significato |
|---|---|---|
| a | Async | Non attendere il risultato di glock (il risultato verrà richiesto più avanti) |
| A | Qualsiasi | Qualsiasi modalità di blocco compatibile è accettabile |
| c | No cache | Quando sbloccato, retrocedi immediatamente il blocco DLM |
| e | No expire | Ignora le richieste di cancellazione del blocco successive |
| E | exact | Deve avere una modalità di blocco esatta |
| F | First | Imposta quando l'holder è il primo ad essere conferito per questo blocco |
| H | Holder | Indica che il blocco richiesto è stato conferito |
| p | Priorità | Metti l'holder in cima alla coda |
| t | Prova | Un blocco "try" |
| T | Try 1CB | Un blocco "try" che invia una callback |
| M | Wait | Imposta mentre in attesa del completamento della richiesta |
Dopo aver identificato il glock che causa il problema, la fase successiva è quella di trovare l'inode relativo. Il numero di glock (n: sulla riga G:) riporta questa informazione. Il suo formato è type/number e se type risulta essere 2, allora saremo in presenza di un glock inode ed il number è un numero inode. Per rintracciare l'inode eseguire
find -inum number dove number è il numero inode modificato da un formato esadecimale nel file di glock in un formato decimale.
Nota
Se eseguite
find su di un file system in presenza di una contesa del blocco, molto probabilmente non farete altro che peggiorare il problema esistente. È consigliato arrestare l'applicazione prima di eseguire find se siete alla ricerca di inode contesi.
Tabella 2.3, «Tipi di glock» mostra il significato dei diversi tipi di glock.
| Numero tipo | Tipo di blocco | Uso |
|---|---|---|
| 1 | Trans | Blocco transazione |
| 2 | Inode | Dati e metadati di Inode |
| 3 | Rgrp | Metadati del gruppo di risorse |
| 4 | Meta | Il superblocco |
| 5 | Iopen | Rilevamento ultimo nodo che ha utilizzato inode |
| 6 | Flock | flock(2) syscall |
| 8 | Quota | Operazioni quota |
| 9 | Diario | Journal mutex |
Se il glock identificato era di un tipo diverso, molto probabilmente sarà di tipo 3: (gruppo risorse). Se visualizzate un numero elevato di processi in attesa per altri tipi di glock in presenza di carichi normali, riportatelo al supporto di Red Hat.
Se visualizzate un certo numero di richieste in coda in un blocco del gruppo delle risorse controllate se è presente un numero elevato di nodi rispetto al numero di gruppi delle risorse presenti nel file system. Oppure controllate se il file system è quasi pieno (causando un tempo più lungo per le ricerche di blocchi liberi). In entrambi i casi sarà possibile aggiungere più storage ed usare il comando
gfs2_grow per estendere il file system.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}