2.9.3. GFS2 ロックダンプを使用した GFS2 パフォーマンスのトラブルシューティング
GFS2 キャシングの使用効率が悪いためにクラスターのパフォーマンスが影響を受けている場合は、I/O の待機時間が大幅に長くなることがあります。GFS2 のロックダンプ情報を利用すると、この問題の原因を究明することができます。
本セクションでは、GFS2 ロックダンプの概要を説明します。GFS2 ロックダンプの詳細は、付録B GFS2 トレースポイントおよび debugfs glocks ファイル を参照してください。
GFS2 ロックダンプ情報は
debugfs
ファイルから収集することができます。このファイルのパス名は以下のとおりです (debugfs
が /sys/kernel/debug/
にマウントされていることが前提です)。
/sys/kernel/debug/gfs2/fsname/glocks
ファイルのコンテンツは一連の行になります。G: で始まる行はそれぞれ 1 つの glock を表し、それに続く 1 行のスペースでインデントされた行は、ファイル内で直前の glock に関する情報の項目を表します。
debugfs
ファイルの最適な使用方法は、アプリケーションに問題の発生中に cat コマンドを使ってファイルの全内容のコピーをとり (RAM が大容量で、かつキャッシュされた inode が多数ある場合には長時間がかかる可能性があります)、後日に結果データを確認する方法です。
注記
debugfs
ファイルのコピーを 2 つ作成すると、役に立つことがあります (2 つ目のコピーを最初のコピーの数秒後または数分後に作成します)。同じ glock 番号に関する 2 つのトレースの所有者情報を比較することで、ワークロードが進行中である (遅いだけ) か、それとも動かなくなったか (この場合は常にバグが原因であるため、Red Hat サポートに報告する必要があります) 判断できます。
debugfs
ファイルの H: (ホルダー) で始まる行は、承認済みまたは承認待機中のロック要求を表します。ホルダーの行 f: の flags フィールドは、W フラグが待機要求を参照し、H フラグが許可された要求を参照しています。待機要求が多数ある glock は、特定の競合が発生している可能性があります。
表2.1「glock フラグ」 は、さまざまな glock フラグの意味を示しており、表2.2「glock ホルダーフラグ」 は、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 を解放する前にデータをディスクにフラッシュする必要があります。 |
フラグ | 名前 | 意味 |
---|---|---|
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 番号になります。find -inum number のコマンドを実行すると、inode をトラッキングすることができます。glocks ファイルにある 16 進形式から 10 進形式に変換した inode 番号が number になります。
警告
ロックの競合が発生しているときにファイルシステムで find を実行すると、事態が悪化する可能性が高くなります。競合している inode を探している場合は、まずアプリケーションを停止してから find を実行することが推奨されます。
表2.3「glock タイプ」 は、さまざまな 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 コマンドを使用してファイルシステムを拡張することで改善することができます。