2.9.3. GFS2 ロックダンプを使用した GFS2 パフォーマンスのトラブルシューティング
GFS2 キャシングの使用効率が悪いためにクラスターのパフォーマンスが影響を受けている場合、I/O の待機時間が長く延長される可能性があります。GFS2 のロックダンプ情報を利用すると、この問題の原因を究明することができます。
本セクションには、GFS2 ロックダンプの概要を記載しています。GFS2 ロックダンプについての詳しい説明は、付録C GFS2 トレースポイントおよび debugfs glocks ファイル を参照してください。
GFS2 ロックダンプ情報は
debugfs ファイルから収集することができます。このファイルのパス名は以下のとおりです (debugfs が /sys/kernel/debug/ にマウントされていることが前提です)。
/sys/kernel/debug/gfs2/fsname/glocks
ファイルの内容は、一連の行から構成されています。G: で始まる行は、それぞれひとつの glock を表し、その下の 1 文字分字下げしてある行はファイル内の直前の行の glock に関連する情報アイテムを表しています。
debugfs ファイルの最適な使用方法は、アプリケーションに問題の発生中に cat コマンドを使ってファイルの全内容のコピーをとり (RAM が大容量で、かつキャッシュされた inode が多数ある場合には長時間がかかる可能性があります)、後日に結果データを確認する方法です。
注記
debugfs ファイルのコピーは 2 つ取っておくと役立つ場合があります。その際、2 つ目のコピーは、最初のコピーから数秒または数分遅らせます。同じ glock 番号に関連する 2 つのトレースでホルダー情報を比較すると、作業負荷が進行しているか (つまり、単なる速度低下)、スタックしているか (その場合は必ずバグなので、Red Hat サポートに直ちに報告する必要があり) を見極めることができます。
debugfs ファイルの H: (ホルダー) で始まる行は、承認済みまたは承認待機中のロック要求を表します。ホルダー行のフラグフィールド f: には、待機中の要求を示す「W」フラグ、または承認済み要求を示す「H」フラグが表示されます。待機中の要求が多数ある glocks は特定の競合が発生している可能性が高くなります。
表2.1「glock フラグ」 では各 glock フラグが示す意味を説明しています。表2.2「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 | LRU 一覧に glock が記載されるとセットされる |
| o | Object | glock がオブジェクトに関連付けられるとセットされる (type 2 glock の場合 inode、type 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 サポートにご報告ください。
リソースグループロックで数多くの待機要求が待ち行列に入っている場合は、複数の理由が考えられます。 その一つとして、ノード数がファイルシステム内のリソースグループ数に比べて多い場合があります。 また、ファイルシステムがほぼ完全に満杯の場合も考えられます (空きブロックの検索に大抵時間がかかる)。いずれの場合も、ストレージを追加した上で
gfs2_grow コマンドを使ってファイルシステムを拡張することで改善することができます。
