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 ファイルの H: (ホルダー) で始まる行は、承認済みまたは承認待機中のロック要求を表します。ホルダー行のフラグフィールド f: には、待機中の要求を示す「W」フラグ、または承認済み要求を示す「H」フラグが表示されます。待機中の要求が多数ある glocks は特定の競合が発生している可能性が高くなります。

表2.1「glock フラグ」 では各 glock フラグが示す意味を説明しています。表2.2「Glock ホルダーフラグ」 では各 glock ホルダーフラグが示す意味を glock ダンプに出現する順序で説明しています。

問題の原因となっている glock を特定したら、次はそれに関連している inode を見つけます。これは、glock 番号 (G: 行にある n:) に示されています。 type/number の形式で記載されており、type が 2 の場合は glock は inode glock で number は inode 番号になります。 find -inum number のコマンドを実行すると、inode をトラッキングすることができます。glocks ファイルにある 16 進形式から 10 進形式に変換した inode 番号が number になります。

表2.3「glock のタイプ」 には、異なる glock のタイプの意味をまとめています。

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

リソースグループロックで数多くの待機要求が待ち行列に入っている場合は、複数の理由が考えられます。 その一つとして、ノード数がファイルシステム内のリソースグループ数に比べて多い場合があります。 また、ファイルシステムがほぼ完全に満杯の場合も考えられます (空きブロックの検索に大抵時間がかかる)。いずれの場合も、ストレージを追加した上で gfs2_grow コマンドを使ってファイルシステムを拡張することで改善することができます。