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

ウェイト・アカウンティングは、IBM i オペレーティング・システムに組み込まれた特許技術で、スレッドやタスクが何もしていないように見えるときに、何をしているかを教えてくれます。

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

ジョブは、作業を行うための基本的なメカニズムです。 どのジョブも少なくとも 1 つのスレッドを持ち、複数のスレッドを持つ場合もあります。 すべてのスレッドはライセンス内部コード (LIC) タスクによって表されますが、タスクも IBM i スレッド・レベル構造なしで存在します。 LIC タスクは通常、 IBM i パフォーマンス・ツールまたは保守ツールを使用する場合を除き、外部からは可視ではありません。 待機アカウンティングの概念はスレッドとタスクの両方に適用されるので、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 サポートに連絡してください。

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