Red Hat Training

A Red Hat training course is available for RHEL 8

6.5. GFS2 ロックダンプを使用した GFS2 パフォーマンスのトラブルシューティング

GFS2 キャシングの使用効率が悪いためにクラスターのパフォーマンスが影響を受けている場合は、I/O の待機時間が大幅に長くなることがあります。GFS2 のロックダンプ情報を利用すると、この問題の原因を特定できます。

GFS2 ロックダンプ情報は debugfs ファイルから収集できます。このファイルのパス名は以下のとおりです (debugfs/sys/kernel/debug/ にマウントされていることが前提です)。

/sys/kernel/debug/gfs2/fsname/glocks

ファイルのコンテンツは一連の行になります。G: で始まる行はそれぞれ 1 つの glock を表し、それに続く 1 行のスペースでインデントされた行は、ファイル内で直前の glock に関する情報の項目を表します。

debugfs ファイルを使用する場合は、cat コマンドを使用して、アプリケーションで問題が発生している間にファイル全体のコピーを取り (RAM が大きくて、キャッシュされた inode がある場合は時間がかかる場合があります)、後日、その結果得られたデータを調べることが最適な方法になります。

注記

debugfs ファイルのコピーを 2 部作成すると便利です。数秒または 1 ~ 2 分かかります。同じ glock 番号に関する 2 つのトレースの所有者情報を比較することで、ワークロードが進行中である (遅いだけ) か、それとも動かなくなったか (この場合は常にバグが原因であるため、Red Hat サポートに報告する必要があります) 判断できます。

debugfs ファイルで H: (ホルダー) で始まる行は、許可された、または許可されるのを待っているロック要求を表します。ホルダーの行 f: の flags フィールドは、W フラグが待機要求を参照し、H フラグが許可された要求を参照しています。待機要求が多数ある glock は、特定の競合が発生している可能性があります。

以下の表は、glock フラグおよび glock ホルダーフラグとその意味について紹介します。

表6.1 glock フラグ

フラグ名前意味

b

Blocking

ロックされたフラグが設定され、DLM から要求された操作がブロックされる可能性があることを示します。このフラグは、降格操作および try ロックに対して消去されます。このフラグの目的は、その他のノードがロックを降格する時間とは無関係に、DLM 応答時間の統計を収集できるようにすることです。

d

Pending demote

遅延している (リモートの) 降格要求

D

Demote

降格要求 (ローカルまたはリモート)

f

Log flush

この glock を解放する前にログをコミットする必要があります。

F

Frozen

リモートのノードからの返信が無視されます (復旧が進行中です)。このフラグは、異なるメカニズムを使用するファイルシステムのフリーズとは関係がなく、復元中にしか使用されません。

i

Invalidate in progress

この glock の下でページを無効にする過程です。

I

Initial

DLM ロックがこの glock と関連付けられる場合に指定します。

l

Locked

glock は、状態を変更中です。

L

LRU

glock が LRU リストにあるときに設定します。

o

Object

glock がオブジェクトに関連付けられている (つまり、タイプ 2 の glock の場合は inode、タイプ 3 の glock の場合はリソースグループ) ときに設定されます。

p

Demote in progress

glock は、降格要求に応答中です。

q

Queued

ホルダーが glock にキューイングされると設定され、glock が保持されるとクリアされますが、残りのホルダーはありません。アルゴリズムの一部として使用され、glock の最小保持時間を計算します。

r

Reply pending

リモートノードから受信した返信の処理を待機中です。

y

Dirty

この glock を解放する前にデータをディスクにフラッシュする必要があります。

表6.2 glock ホルダーフラグ

フラグ名前意味

a

Async

glock の結果を待ちません (結果は後でポーリングします)。

A

Any

互換性のあるロックモードはすべて受け入れ可能です。

c

No cache

ロック解除時に DLM ロックを即時に降格します。

e

No expire

後続のロック取り消し要求を無視します。

E

exact

完全一致するロックモードでなければなりません。

F

First

ホルダーがこのロックに最初に許可される場合に指定します。

H

Holder

要求したロックが許可されたことを示します。

p

Priority

キューの先頭にある待機ホルダー

t

Try

try ロックです。

T

Try 1CB

コールバックを送信する try ロックです。

W

Wait

要求完了の待機中にセットされます。

問題の原因になっている glock を特定したら、それがどの inode に関連しているかを調べることが次のステップになります。glock 番号 (G: 行の n:) はこれを示します。これは、type/number の形式になっており、type が 2 の場合、glock は inode glock となり、number は inode の番号になります。inode を追跡するには、find -inum number を実行できます。ここでの number は、glock のファイルを 16 進数から 10 進数に変換した inode になります。

警告

ロックの競合が発生しているときにファイルシステムで find コマンドを実行すると、問題が悪化する可能性が高くなります。競合する inode を探す際に、アプリケーションを停止してから find コマンドを実行することを推奨します。

以下の表は、さまざまな glock タイプの意味を示しています。

表6.3 glock タイプ

タイプ番号ロックタイプ使用方法

1

Trans

トランザクションのロック

2

Inode

inode のメタデータとデータ

3

Rgrp

リソースグループのメタデータ

4

Meta

スーパーブロック

5

Iopen

最後に閉じた inode の検出

6

Flock

flock(2) syscall

8

Quota

クォータ操作

9

Journal

ジャーナルミューテックス

識別された glock のタイプが異なれば、それはタイプ 3: (リソースグループ) である可能性が最も高いです。通常の負荷下において他のタイプの glock を待機しているプロセスが多数ある場合は、Red Hat サポートに報告してください。

リソースグループロックでキューに置かれている待機要求が多く表示され場合は、複数の理由が考えられます。1 つは、ファイルシステム内のリソースグループ数と比べ、多くのノードが存在するためです。または、ファイルシステムがほぼ満杯になっている可能性もあります (平均して、空きブロックの検索時間が長い場合があります)。どちらの場合も状況を改善するには、ストレージを追加し、gfs2_grow コマンドを使用してファイルシステムを拡張します。