IBM i 待機アカウンティングの基礎

待機アカウンティングは IBM® i オペレーティング・システムに組み込まれている特許取得済みテクノロジーであり、スレッドまたはタスクが何もしていないように見えるときにそれが何をしているかをユーザーが分かるようにします。

スレッドまたはタスクは、実行中でなければ待機しています。 待機アカウンティング (IBM i だけにしかない概念) は、パフォーマンスの詳細分析のための非常に強力な機能です。ここでは、待機の概念とスレッドが待機する理由、およびパフォーマンス上の問題をトラブルシューティングする場合や単にアプリケーションのパフォーマンスを向上させる場合に待機アカウンティングを使用する方法について焦点を当てていきます。

ジョブは、作業を行うための基本的なメカニズムです。 どのジョブも少なくとも 1 つのスレッドを持ち、複数のスレッドを持つ場合もあります。 1 つ 1 つのスレッドがライセンス内部コード (LIC) タスクによって表されますが、IBM i のスレッド・レベルの構造がなくてもタスクは存在します。LIC タスクは通常、IBM i Performance Tools またはサービス・ツール以外では外部から不可視です。待機アカウンティングの概念はスレッドとタスクの両方に適用されるので、1 つの実行可能作業部分を指す場合にスレッドとタスクという用語を使用します。

スレッドまたはタスクが取りうる基本状態として、次の 2 つがあります。

• プロセッサーで実行中。「実行中」状態です。
• プロセッサーで実行待機中。

  主に次の 3 つの待ち状態があります。

  1. 実行準備済みでプロセッサー待ち。特殊な待ち状態であり、一般に CPU キューイング と呼ばれます。これは、スレッドまたはタスクが待ち行列に入れられていて、CPU での実行を待機していることを意味します。CPU キューイングが起こるのには、いくつかの異なる理由があります。例えば、区画が過負荷状態であり、区画の受け入れ可能限度を超える作業がある場合、作業は待ち行列に入れられて CPU を待機することになります。 これは、ランプ・メーターが設置された高速道路に例えることができます。高速道路が混んでいるときは、ランプ・メーターの信号が赤になるので、車は止まって本線に入れるようになるまで待たなければなりません。 論理区画と同時マルチスレッド化も、CPU キューイングにつながることがあります。
  2. アイドル待機。アイドル待機は、予期される正常な待ち状態です。 アイドル待機になるのは、スレッドが外部入力を待っているときです。 この入力は、ユーザー、ネットワーク、または別のアプリケーションからもたらされる場合があります。 その入力を受け取るまで、行わなければならない作業はありません。
  3. ブロック待機。ブロック待機は、共有リソースへのアクセスを同期化するための直列化メカニズムの結果です。 ブロック待機は、予期される正常な待ち状態である場合があります。 例として、表の行の更新、ディスク入出力操作、または通信入出力操作のための直列化アクセスが挙げられます。 一方、ブロック待機が正常でない場合もあります。 待ち状態を待機アカウンティングを使用して分析できるのは、このような予期しないブロック・ポイントのときです。

スレッドまたはタスクの存続時間を、実行または待機に費やした時間に分解してグラフィカルに考えることができます。 このグラフィカル記述を「実行/待機時間こん跡」といいます。 このこん跡は、大まかに次のようになります。

従来、アプリケーションのパフォーマンスを向上させるための焦点は、アプリケーションに CPU をできるだけ効率的に使用させることに当てられていました。 待機アカウンティング機能のある IBM i では、待機に費やした時間を調べて、その待機時間の要因を把握できます。削減または除去できる待機要素がある場合は、全体パフォーマンスも向上させることができます。

IBM i オペレーティング・システムにおけるほぼすべての待ち状態は、識別されており列挙済みです。換言すれば、固有待機ポイントそれぞれに数値が割り当てられています。これが可能なのは、IBM がライセンス内部コードとオペレーティング・システムの両方を完全に管理しているからです。 IBM i 6.1 のリリースの時点で、固有待ち状態は 268 あります。スレッドおよびタスクごとに 250 を超える固有待ち状態を追跡すると、ストレージを過剰に消費することになるので、グループ化アプローチが採用されています。 固有待ち状態はそれぞれ、32 あるグループ (「バケット」) のうちの 1 つに割り当てられています。 スレッドまたはタスクが待ち状態に入ったときと待ち状態から抜けたとき、タスク・ディスパッチャーが待ち状態を該当グループにマッピングします。

待機アカウンティングを使用して実行/待機時間こん跡を調べることにより、スレッドまたはタスクの待機時間について、その構成要素を識別できるようになりました。 以下に例を示します。

スレッドの待機時間の要因がディスク・データの読み取りと書き込み、直列化アクセスのためのレコードのロッキング、およびデータのジャーナリングだった場合、待機をこのように分解してとらえることができます。 関係している待機のタイプが分かると、確認すべきことがいくつか出てきます。 この例の場合、その中には以下のような事柄が含まれます。

• ディスク読み取りでページ不在になっていないか。そうであれば、プール・サイズは適切か。
• ディスクの読み取りと書き込みの要因になっているのはどのプログラムか。削減または除去できる不必要な入出力はないか。 あるいは、入出力を非同期で行えないか。
• レコード・ロッキング・ストラテジーは最適か。あるいは、レコードを不必要にロックしていないか。
• ジャーナル処理されているのはどのファイルか。すべてのジャーナルが必要か、また最適に構成されているか。

定義済みの 32 の待機グループ (「バケット」) は、以下のとおりです。 待機グループの定義はリリースによって異なり、今後変更される可能性があります。

1. CPU 上のディスパッチ時間
2. CPU キューイング
3. 予約済み
4. その他の待機
5. ディスク・ページ不在
6. 障害なしディスク読み取り
7. ディスク・スペース使用の競合
8. ディスク操作開始の競合
9. ディスク書き込み
10. ディスク (その他)
11. ジャーナリング
12. セマフォーの競合
13. mutex の競合
14. マシン・レベルのゲートの直列化 - IBM サポートをコール
15. 占有の競合 - IBM サポートをコール
16. データベース・レコード・ロックの競合
17. オブジェクト・ロックの競合
18. 不適格な待機
19. 主記憶域プールの競合 - IBM サポートをコール
20. 活動時ジャーナル保管
21. 予約済み
22. 予約済み
23. 予約済み
24. ソケット送信
25. ソケット受信
26. ソケット (その他)
27. IFS
28. PASE
29. データ待ち行列受け取り
30. アイドル/作業待ち
31. 同期トークンの競合
32. 異常な競合 - IBM サポートをコール

これらの待機グループの多くは、アプリケーションの待機分析をするうえで表面的なものにすぎない場合もあります。 これらの状況でアプリケーションが何を行っていてなぜ待機しているのかを理解すると、不必要な待機を削減したり除去したりする助けになることがあります。