はじめに
第1回では、WRKSYSSTS と WRKACTJOB を使った初動切り分けを紹介しました。ところが実際の現場では、CPUが30～40%程度なのに『遅い』というケースがあります。このような場合に理解しておきたいのが、プールと待ち時間です。
IBM iでは、ジョブがCPUを使える状態でも、プールの活動レベルやページの取り込みなどの影響で、すぐに処理を進められないことがあります。第2回では、WRKSYSSTS のプール欄を『数字を見るだけ』から『意味を考えて次の調査へ進む』ための読み方に変えていきます。
1. まず遅いジョブとプールを結び付ける
WRKJOB JOB(USER/JOBNAME) → 1. ジョブ状況属性の表示
WRKSYSSTS を調査するときに最初にやることは、遅いジョブがどのプールで動いているかを確認することです。システム内には複数のプールが存在するため、システム全体の不在(Fault)だけを見ても対象業務と関係がない場合があります。
遅いJOB-A → プール 2
➔WRKSYSSTSでプール 2の値を重点的に確認
この『ジョブとプールを関連付ける』考え方を持つだけで、プール調査はかなり分かりやすくなります。
2. プールサイズ(PoolSize)と最大活動(Max Active)
WRKSYSSTS
プールサイズ(PoolSize)は、そのプールに割り当てられている主記憶の大きさです。最大活動(Max Active)は、そのプール内で同時に活動できる処理数に関係します。どちらか一方だけを見て設定変更するのではなく、実際のワークロードや不在(Fault)、INELの発生と合わせて判断します。
例えば最大活動(Max Active)が小さすぎると、実行したいジョブがINELになりやすくなる可能性があります。しかし、INELを減らすために最大活動(Max Active)だけを大きくすると、今度は同時に動く処理が増え、メモリーやI/Oの競合が増える可能性があります。
3. DB 不在(Fault)とNon-DB 不在(Fault)
DB 不在(Fault)は、必要なデータベースページが主記憶上になく、補助記憶から取り込む必要が生じた事象です。Non-DB 不在(Fault)はデータベース以外のページに関する不在(Fault)です。名前に不在(Fault)と付いているため『障害』のように見えますが、不在(Fault)自体は通常動作でも発生します。
【例】
平常時 DB 不在(Fault)：150～250/sec
障害時 DB 不在(Fault)：2,500/sec
この例で注目するのは、2,500という数字そのものではなく、平常時から約10倍に増えている点です。処理量が増えたのか、プールサイズ(PoolSize)が足りないのか、大量データを読む処理が追加されたのか、ディスクI/Oも増えているのか、と仮説を広げます。
4. 活動→待機(Active->Wait)と活動→不適格(Active->Inel)
活動→待機(Active->Wait)は、実行中の処理が何らかの待ち状態へ移った回数です。I/Oやイベント待ちなど正常な処理でも発生するため、多いだけで異常とは言えません。
一方、活動→不適格(Active->Inel)が増加し、同じ時間帯に WRKACTJOB で複数の業務ジョブが実行不適格(INEL)になっているなら、活動レベルとの関連を調べる価値があります。
WRKACTJOB：JOB-A INEL / JOB-B INEL / JOB-C INEL
WRKSYSSTS：対象プールの活動→不適格(Active->Inel)が平常時より急増
ここまで揃って初めて、『対象プールで実行資格待ちが性能に影響しているかもしれない』という仮説が立ちます。
5. WRKSHRPOOLとQPFRADJ
WRKSHRPOOL
DSPSYSVAL SYSVAL(QPFRADJ)
WRKSHRPOOL では、共有メモリー・プールの設定とあわせて、ページング・オプションが「*FIXED」か「*CALC」かも確認します。
*CALC はシステム側でページング特性を計算する設定で、*FIXED は固定して運用する設定です。FIXEDになっている場合でも、すぐにCALCへ変更するのではなく、意図的に固定している可能性を考慮します。過去の性能問題への対応や運用設計上の理由でFIXEDとしている場合もあるため、設計書や変更履歴、運用担当者への確認などから設定した経緯を確認します。
あわせて DSPSYSVAL SYSVAL(QPFRADJ) で性能調整の設定を確認し、実行不適格（INEL）や不在(Fault)、処理負荷の状況と関連付けて判断します。
6. 不在(Fault)とINELの組み合わせで次の一手を決める
| 不在(Fault) | INEL | 考え方 |
|---|---|---|
| 低い | 少ない | プール以外を優先して調査 |
| 高い | 少ない | プールサイズ(PoolSize)、処理量、I/O増加を確認 |
| 低い | 多い | 活動レベル、最大活動(Max Active)を確認 |
| 高い | 多い | プール構成とワークロードを総合的に調査 |
7. CPUが低いならWaitを考える
処理時間 = CPUで実行した時間 + 何かを待っていた時間
例えば30秒かかった処理のCPU時間が2秒しかないなら、残りの時間はCPU以外の要因に使われています。ロック待ち、ディスクI/O、通信待ち、イベント待ちなどが候補になります。
まず WRKACTJOB のStatus（状況）を見て、LCKW、INEL、CMNWなどの状態から待ちの種類を推測し、必要に応じて一段深い性能データへ進むと理解しやすくなります。
8. WRKSYSACTで一段深く見る
WRKSYSACT SEQ(*CPU)
WRKSYSACT SEQ(*IO)
WRKSYSACT SEQ(*SQLCPU)
利用できる環境では、WRKSYSACT を使うことで現在のシステム活動をさらに詳しく確認できます。*CPU はCPU消費、*IO はI/O活動、*SQLCPU はSQL処理を意識した絞り込みに利用できます。最初から WRKSYSACT だけを見るのではなく、WRKSYSSTS と WRKACTJOB で方向を決めた後に使うと効果的です。
第2回まとめ
CPUが低いのに遅いときは、『CPU以外で時間を使っている』と考えることが第一歩です。対象ジョブとプールを結び付け、不在(Fault)、INEL、活動レベル、I/O、Waitを順番に確認することで、単なる数値監視から一歩進んだ性能切り分けができるようになります。
IBM i 運用・パフォーマンス障害切り分けチェックポイント（全4回）
第1回｜パフォーマンス低下発生時の初動切り分けについて
第2回｜メモリー・プールに起因するパフォーマンス低下の切り分けについて
第3回｜ストレージ逼迫・ディスク高負荷でIBM iが遅いときの切り分けについて
第4回｜パフォーマンス障害の事後分析と情報収集方法