はじめに
運用担当をしていると、「IBM iが遅いです」「いつもより画面の反応が悪いです」という問い合わせを受けることがあります。
このとき最も難しいのは、コマンドを知らないことよりも、どこから確認すればよいか分からないことです。CPU、メモリー、ディスク、ジョブ、ロック、通信など、性能に影響する要素は複数あります。
本記事では、現在発生している性能低下を対象に、最初の10～15分で実施したい確認を整理します。
1. 最初に聞くべきこと
問い合わせを受けた直後に WRKSYSSTS を実行したくなりますが、その前に現象を具体化します。例えば『遅い』という言葉でも、5250画面だけが遅いのか、バッチが終わらないのか、すべての利用者が遅いのかで、見るべき場所は変わります。
| 確認事項 | 理由 |
|---|---|
| 発生時刻 | 性能データやログと時刻を合わせる |
| 影響範囲 | 全体資源か個別ジョブかを切り分ける |
| 対象処理 | 対象ジョブやサブシステムを絞る |
| 継続状況 | 現在値を見るか過去データを見るか決める |
| 通常との差 | 『遅い』を数値化する |
| 変更点 | 原因候補を作る |
2. WRKSYSSTSでシステム全体を俯瞰する
WRKSYSSTS
ここではCPU使用率、システムASP使用率、プール、システム内のジョブ数などを一画面で確認できます。大切なのは、表示された値を単独で『高い／低い』と判断しないことです。
例えばCPUが85%でも、毎日同じ時間に集計バッチが動き、通常も80～90%で処理が完了しているなら、その値だけで異常とは言えません。一方、普段30%前後のシステムが問い合わせ時だけ90%になっているなら、平常時との差が原因調査の強い手掛かりになります。
判断の基準
- 平常時：CPU 25～35%
- 障害時：CPU 91%
➔ 『90%だから異常』ではなく『普段との差が大きい』ことを重視する
3. CPUが高いならWRKACTJOBへ
WRKACTJOB
WRKSYSSTS でCPUが高いことが分かっても、原因はまだ分かりません。次に WRKACTJOB で、どのジョブがCPUを使っているかを確認します。
【表示例】
JOB-A CPU 3%
JOB-B CPU 5%
JOB-C CPU 64% <-- 突出している
JOB-D CPU 2%
この例では JOB-C が突出しています。正常な大量集計やバックアップ処理でCPUを使っている可能性もあるため、ジョブ名、ユーザー、開始時刻、業務スケジュールを確認して『本来この時間に動く処理か』を判断します。
4. CPUが低い場合はStatus(状況)を見る
性能障害でよくある誤解が、『CPUが低い＝システムは暇＝問題なし』という判断です。処理はCPUを使っている時間だけでなく、ロック、I/O、通信、メッセージなどを待っている時間でも遅くなります。
| Status(状況) | 考え方 | 次の確認 |
|---|---|---|
| RUN | 現在実行中 | CPU、処理内容、経過時間 |
| MSGW | メッセージ応答待ち |
WRKJOB、ジョブログ |
| LCKW | ロック待ち |
WRKOBJLCK、ロック保持ジョブ |
| INEL | 実行資格待ち | プール、最大活動(Max Active) |
| CMNW | 通信待ち | 通信先、関連ジョブ |
| TIMW | 時間待ち | 意図したWaitか |
| DSPW | 画面入力待ち | 対話ジョブでは正常なことが多い |
| DEQW | Dequeue待ち | サーバージョブ等では正常な場合あり |
5. 対象範囲が分かっているなら絞り込む
WRKSBSJOB SBS(サブシステム名)
WRKUSRJOB USER(ユーザー名)
全体障害ではなく、特定の業務やユーザーだけが遅い場合は、WRKACTJOB の全ジョブを眺め続けるよりも、サブシステムやユーザー単位で対象を絞った方が効率的です。
例えば『夜間バッチだけ遅い』なら対象バッチサブシステムを確認し、『Aさんだけ画面が固まる』なら WRKUSRJOB でそのユーザーのジョブを確認する、といった使い分けができます。
6. WRKJOBで原因候補を深掘りする
WRKJOB JOB(USER/JOBNAME)
WRKACTJOB で怪しいジョブを見つけたら WRKJOB へ進みます。ここからジョブログなどを確認し、『そのジョブが今どこで何をしているか』を具体化します。
- 1. ジョブログ：直前に発生したメッセージやエラーを確認する
- 2. ジョブ属性：サブシステムやプールとの関連を確認する
DSPJOBLOG JOB(USER/JOBNAME) OUTPUT(*PRINT)
障害時の証跡を残したい場合は、運用ルールに応じてジョブログをスプール出力しておくと、事象復旧後の振り返りにも使えます。
7. LCKWならロック保持側を見る
WRKOBJLCK OBJ(LIB/OBJ) OBJTYPE(*FILE)
LCKW になっているジョブは『遅いジョブ』ではありますが、原因ジョブとは限りません。別のジョブがオブジェクトをロックしたまま長時間処理している場合、LCKW 側は被害を受けているだけです。そのため、待たされているジョブだけでなく、ロックを保持している側を追うことが重要です。
8. システムメッセージとディスクも確認する
DSPMSG QSYSOPR
WRKDSKSTS
CPUやジョブだけで説明できない場合は、QSYSOPR に装置・通信・システム関連のメッセージがないか確認します。さらに WRKDSKSTS でディスクI/Oの偏りを確認します。性能障害は一つの画面だけで原因を決めず、複数の情報を時刻で関連付けることが重要です。
第1回まとめ
初動で最も重要なのは、原因をすぐに決めることではありません。『全体か一部か』『CPUで説明できるか』『待ちが発生しているか』『特定ジョブか』を順番に絞ることで、次に実行するコマンドが自然に決まります。
IBM i 運用・パフォーマンス障害切り分けチェックポイント（全4回）
第1回｜パフォーマンス低下発生時の初動切り分けについて
第2回｜メモリー・プールに起因するパフォーマンス低下の切り分けについて
第3回｜ストレージ逼迫・ディスク高負荷でIBM iが遅いときの切り分けについて
第4回｜パフォーマンス障害の事後分析と情報収集方法