Suchen

2.9.3. Suche und Bereinigung von Problemen bei der GFS2-Leistung mit GFS2 Lock Dump

download PDF
Falls die Leistung Ihres Clusters unter ineffizienter Nutzung des GFS2-Cachings leidet, bemerken Sie möglicherweise zunehmend große I/O-Wartezeiten. Sie können die Informationen des GFS2 Lock Dump nutzen, um der Ursache des Problems auf den Grund zu gehen.
Dieser Abschnitt enthält einen Überblick über den GFS2 Lock Dump. Eine vollständige Beschreibung des GFS2 Lock Dumps finden Sie in Anhang C, GFS2-Tracepoints und die debugfs-Glocks-Datei.
Die Informationen des GFS2 Lock Dumps können aus der debugfs-Datei entnommen werden, die sich im folgenden Pfad befindet, sofern debugfs unter /sys/kernel/debug/ eingehängt ist:
/sys/kernel/debug/gfs2/fsname/glocks
Die Datei enthält eine Reihe von Zeilen. Jede Zeile, die mit einem G: beginnt, steht für einen Glock und die folgenden Zeilen – um ein Leerzeichen eingerückt – stehen für eine Information, die sich auf das in der Datei darüberstehende Glock bezieht.
Erstellen Sie am besten mithilfe des cat-Befehls eine Kopie des gesamten Inhalts der debugfs-Datei (dies kann eine längere Zeit dauern, falls Sie eine große Menge RAM und zahlreiche gecachte Inodes haben), während bei der Applikation Probleme auftreten, und schauen Sie sich die so erstellten Daten zu einem späteren Zeitpunkt an.

Anmerkung

Es kann hilfreich sein, zwei Kopien der debugfs-Datei zu erstellen, im Abstand von ein paar Sekunden oder ein bis zwei Minuten. Vergleichen Sie in den zwei Kopien nun die Halterinformationen derselben Glock-Nummer. Anhand dessen sollten Sie feststellen können, ob die Verarbeitung Fortschritte macht (also nur langsam ist) oder ob sie hängen geblieben ist (was immer auf einen Fehler hindeutet und umgehend dem Red Hat Support gemeldet werden sollte).
Jede Zeile in der debugfs-Datei, die mit H: (Halter) beginnt, steht für eine Sperranfrage, die entweder bereits gewährt wurde oder darauf wartet, gewährt zu werden. Das Flags-Feld auf der Halterzeile f: zeigt an, was von beidem der Fall ist: Das „W“-Flag kennzeichnet eine wartende Anfrage, das „H“-Flag kennzeichnet eine gewährte Anfrage. Diejenigen Glocks mit einer hohen Anzahl wartender Anfragen sind wahrscheinlich diejenigen mit Konflikten.
Tabelle 2.1, »Glock-Flags« zeigt die Bedeutungen der verschiedenen Glock-Flags und Tabelle 2.2, »Glock-Halter-Flags« zeigt die Bedeutungen der verschiedenen Glock-Halter-Flags in der Reihenfolge, in der Sie in den Glock-Dumps auftreten.
Tabelle 2.1. Glock-Flags
FlagNameBedeutung
bBlockingGültig, wenn das „locked“-Flag gesetzt ist. Zeigt an, dass die Operation, die vom DLM angefordert wurde, sperren könnte. Dieses Flag wird für „demote“-Operationen und für „try“-Sperren entfernt. Der Zweck dieses Flags ist es, das Sammeln von Statistiken über die DLM-Antwortzeiten zu ermöglichen, unabhängig von der Zeit, die andere Knoten zum Herabstufen von Sperren benötigen.
dPending demoteEine wartende Anfrage zum Herabstufen (remote)
DDemoteEine Anfrage zum Herabstufen (lokal oder remote)
fLog flushDas Protokoll muss festgeschrieben werden, bevor dieses Glock freigegeben werden kann
FFrozenAntworten von Remote-Knoten werden ignoriert, eine Wiederherstellung läuft. Dieses Flag hat nichts mit dem Dateisystem-Freeze zu tun, das einen anderen Mechanismus verwendet, sondern wird nur zur Wiederherstellung verwendet.
iInvalidate in progressSeiten unter diesem Glock werden derzeit ungültig gemacht (invalidiert)
IInitialGesetzt, wenn eine DLM-Sperre mit diesem Glock verknüpft ist
lLockedDas Glock ändert derzeit seinen Status
LLRUGesetzt, wenn das Glock auf der LRU-Liste ist
oObjectGesetzt, wenn das Glock einem Objekt zugeordnet ist (d. h. einem Inode für Typ-2-Glocks und einer Ressourcengruppe für Typ-3-Glocks)
pDemote in progressDas Glock antwortet derzeit auf eine Anfrage zum Herabstufen
qQueuedGesetzt, wenn ein Halter der Warteschlange eines Glocks hinzugefügt wird, und gelöscht, wenn das Glock noch gehalten wird, es jedoch keine verbleibenden Halter gibt. Verwendet als Teil des Algorithmus, der die minimale Haltezeit für ein Glock berechnet.
rReply pendingVon Remote-Knoten erhaltene Antwort wartet auf Verarbeitung
yDirtyDaten müssen auf die Festplatte überschrieben werden, bevor dieses Glock freigegeben werden kann
Tabelle 2.2. Glock-Halter-Flags
FlagNameBedeutung
aAsyncNicht auf das Glock-Ergebnis warten (Ergebnis wird später abgerufen)
AAnyJeder kompatible Sperrmodus ist zulässig
cNo cacheWenn nicht gesperrt, sofort DLM-Sperre herabstufen
eNo expireNachfolgende Anfragen zur Aufhebung der Sperre ignorieren
EexactMuss den exakten Sperrmodus haben
FFirstGesetzt, wenn der Halter der Erste ist, dem diese Sperre gewährt wird
HHolderZeigt an, dass die angeforderte Sperre gewährt wird
pPriorityReiht Halter an der Spitze der Warteschlange ein
tTryEine „try“-Sperre
TTry 1CBEine „try“-Sperre, die einen Callback sendet
WWaitGesetzt, während auf den Abschluss einer Anfrage gewartet wird
Nachdem Sie herausgefunden haben, welches Glock das Problem verursacht, müssen Sie nun feststellen, auf welchen Inode es sich bezieht. Dies wird angezeigt durch die Glock-Nummer (n: auf der Zeile G:) im Format type/number. Falls type 2 ist, dann ist das Glock ein Inode-Glock und die number ist eine Inode-Nummer. Um den Inode zu finden, können Sie den Befehl find -inum number ausführen, wobei number die Inode-Nummer ist, die aus dem Hexadezimalformat in der Glocks-Datei in ein Dezimalformat konvertiert wurde.

Anmerkung

Falls Sie den find-Befehl auf einem Dateisystem durchführen, während dort Sperrkonflikte auftreten, werden Sie wahrscheinlich das Problem dadurch noch verschlimmern. Wenn Sie nach Inode-Konflikten suchen, ist es ratsam, die Applikation vor der Ausführung des find-Befehls zu stoppen.
Tabelle 2.3, »Glock-Typen« zeigt die Bedeutungen der verschiedenen Glock-Typen.
Tabelle 2.3. Glock-Typen
TypnummerSperrtypVerwendung
1TransTransaktionssperre
2InodeInode-Metadaten und -Daten
3RgrpRessourcengruppen-Metadaten
4MetaDer Superblock
5IopenFeststellung des letzten Schließers des Inodes
6Flockflock(2)-Systemaufruf
8QuotaKontingentoperationen
9JournalJournal-Mutex
Falls das identifizierte Glock einem anderen Typ angehört, dann am ehesten Typ 3: (Ressourcengruppe). Falls Sie unter normaler Auslastung eine erhebliche Anzahl von Prozessen sehen, die auf andere Glock-Typen warten, dann melden Sie dies bitte dem Red Hat Support.
Falls Sie eine Reihe von Anfragen in der Warteschlange sehen, die auf eine Ressourcengruppensperre warten, könnte dies eine Reihe von Ursachen haben. Zum einen gibt es unter Umständen eine hohe Anzahl von Knoten im Vergleich zur Anzahl von Ressourcengruppen im Dateisystem. Zum anderen könnte das Dateisystem unter Umständen beinahe voll sein (wodurch die Suche nach freien Blöcken durchschnittlich länger braucht). In beiden Fällen kann die Situation verbessert werden, indem mehr Speicher hinzugefügt wird und das Dateisystem mithilfe des Befehls gfs2_grow vergrößert wird.
Red Hat logoGithubRedditYoutubeTwitter

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat Dokumentation

Wir helfen Red Hat Benutzern, mit unseren Produkten und Diensten innovativ zu sein und ihre Ziele zu erreichen – mit Inhalten, denen sie vertrauen können.

Mehr Inklusion in Open Source

Red Hat hat sich verpflichtet, problematische Sprache in unserem Code, unserer Dokumentation und unseren Web-Eigenschaften zu ersetzen. Weitere Einzelheiten finden Sie in Red Hat Blog.

Über Red Hat

Wir liefern gehärtete Lösungen, die es Unternehmen leichter machen, plattform- und umgebungsübergreifend zu arbeiten, vom zentralen Rechenzentrum bis zum Netzwerkrand.

© 2024 Red Hat, Inc.