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 ホルダーフラグとその意味を紹介します。
| フラグ | 名前 | 意味 |
|---|---|---|
| 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 の番号になります。inode を追跡するには、find -inum number を実行できます。ここでの number は、glock のファイルを 16 進数から 10 進数に変換した inode になります。
ロックの競合が発生しているときにファイルシステムで find コマンドを実行すると、問題が悪化する可能性が高くなります。競合する inode を探す際に、アプリケーションを停止してから find コマンドを実行することを推奨します。
以下の表は、さまざまな glock タイプの意味を示しています。
| タイプ番号 | ロックタイプ | 使用方法 |
|---|---|---|
| 1 | Trans | トランザクションのロック |
| 2 | Inode | inode のメタデータとデータ |
| 3 | Rgrp | リソースグループのメタデータ |
| 4 | Meta | スーパーブロック |
| 5 | Iopen | 最後に閉じた inode の検出 |
| 6 | Flock |
|
| 8 | Quota | クォータ操作 |
| 9 | Journal | ジャーナルミューテックス |
識別された glock のタイプが異なれば、それはタイプ 3: (リソースグループ) である可能性が最も高いです。通常の負荷下において他のタイプの glock を待機しているプロセスが多数ある場合は、Red Hat サポートに報告してください。
リソースグループロックでキューに置かれている待機要求が多く表示され場合は、複数の理由が考えられます。1 つは、ファイルシステム内のリソースグループ数と比べ、多くのノードが存在するためです。または、ファイルシステムがほぼ満杯になっている可能性もあります (平均して、空きブロックの検索時間が長い場合があります)。どちらの場合も状況を改善するには、ストレージを追加し、gfs2_grow コマンドを使用してファイルシステムを拡張します。