はじめに
IBM iの性能障害では、CPUやプールだけでなく、ストレージ容量とディスクI/Oも重要な確認ポイントです。ただし、『システム ASP使用率が高い』ことと『ディスクI/Oが高い』ことは別の問題です。容量の余裕とI/O性能を分けて考えないと、不要な削除や誤った原因判断につながります。
本記事では、システム ASP逼迫時に何を調べるか、WRKDSKSTS でディスク高負荷を見つけた後にどう原因ジョブへつなげるか、さらにハードウェア側まで疑う場合の流れを整理します。
1. 容量逼迫とI/O高負荷は別物
WRKSYSSTS
まずシステム ASP使用率を確認します。システム ASPは保存領域の使用状況を見る指標です。一方、ディスクがどれだけ忙しく動いているかは WRKDSKSTS などで確認します。
- 容量の問題：システム ASP 95%に近づいている
- I/Oの問題：システム ASP 70%でもDisk I/Oが集中している
つまり、ASPに空きがあるからディスク性能に問題がないとは言えませんし、ASP使用率が高いから必ず性能が悪いとも限りません。最初にこの二つを分けることが重要です。
2. システム ASP逼迫時は『何を消すか』より『なぜ増えたか』
運用上は80%を超えたら増加傾向を確認、90%を超えたら容量確保を具体的に検討、95%付近では緊急度を高める、といった社内基準を設定すると監視しやすくなります。ただし、これらは一律のIBM公式障害判定値ではなく、調査開始の目安です。
例えば先週70%だったASPが今週85%になった場合、85%という現在値よりも、短期間で15ポイント増えたことの方が重要です。削除して空きを作っても、増加原因が残っていれば再び逼迫します。
3. ジャーナルレシーバーを確認する
WRKJRNRCV JRNRCV(*ALL/*ALL)
ジャーナルを利用しているシステムでは、ジャーナルレシーバーが容量を大きく使用することがあります。ただし、レシーバーはバックアップ、監査、レプリケーション、リカバリーなどの運用要件と関係するため、古いという理由だけで削除してはいけません。
容量逼迫時ほど『消せそうなもの』を探したくなりますが、ジャーナル運用を確認し、保存期間や削除手順に従って対応することが重要です。
5. IFSの増加を確認する
RTVDIRINF
PRTDIRINF
SBMJOB CMD(CALL PGM(QSRSRV) PARM("METRICS" '/' "EPFS"))
IFSを利用するアプリケーションでは、ログ、PDF、CSV、連携ファイル、一時ファイルなどが蓄積することがあります。ディレクトリー情報を取得し、どの階層が大きいかを段階的に絞り込みます。
例えば /app/log だけが急増している場合は、ログを削除して終わりではなく、ログローテーションの失敗、アプリケーションエラーによる大量出力など、増加した理由まで確認します。
6. ASPに余裕があるのに遅いならWRKDSKSTS
WRKDSKSTS
システム ASPに十分な空きがあるにもかかわらず処理が遅い場合は、ディスクI/Oを確認します。WRKDSKSTS では、装置ごとのBusy状況やRead/Write活動を確認し、全体が高いのか、一部装置だけが突出しているのかを見ます。
例えば多くの装置が20～30%程度なのに、一部だけ80%前後で推移している場合は、その偏りを調査対象にします。ただし瞬間的な値だけで判断せず、処理時間帯、バックアップ、大量バッチなどとの関係を確認します。
7. 『誰がI/Oを出しているか』を追う
WRKACTJOB
WRKSYSACT SEQ(*IO)
WRKJOB JOB(123456/USER/JOBNAME)
WRKDSKSTS でI/O高負荷が分かっても、原因ジョブまでは分かりません。WRKACTJOB で長時間ジョブや大量処理を確認し、利用可能な環境では WRKSYSACT SEQ(*IO) でI/O活動の大きいジョブ／タスクを絞ります。
候補を見つけたら WRKJOB でコールスタック、オープンファイル、ジョブログを確認します。CPU使用率が低いジョブでも、大量I/OやI/O待ちによって処理時間が長くなることがあるため、CPUだけで候補から外さないことが重要です。
9. ハードウェア障害の場合
DSPMSG QSYSOPR
WRKPRB
STRSST
一部装置だけが継続的に異常な挙動を示す、装置関連メッセージがある、ソフトウェア側の処理だけでは説明できない、といった場合はハードウェア側へ調査範囲を広げます。
QSYSOPR、問題ログを確認し、必要に応じて STRSST からプロダクト活動ログ(Product activity log)を確認します。性能低下時刻とPALのエントリー時刻、対象リソースが一致しているかを見ることで、ストレージ／ハードウェア側の問題を切り分けます。
10. 復旧済みならCollection Services
CHKPFRCOL
CRTPFRDTA FROMMGTCOL(ライブラリー/収集オブジェクト)
問い合わせ時に正常に戻っている場合、現在の WRKDSKSTS だけでは障害時のI/O状況は分かりません。Collection Servicesから障害時刻のCPU、Disk I/O、プール、ジョブ活動を確認し、平常時と比較します。
11. やってはいけない対応
- 容量を空けるためだけに、用途不明のオブジェクトやIFSファイルを削除する
- 古いという理由だけでジャーナルレシーバーを削除する
- システム ASP使用率が高いことだけで性能低下の原因と断定する
-
WRKDSKSTSの瞬間値だけでディスク障害と判断する - CPU使用率が低いから性能問題ではないと結論付ける
-
STRSSTで調査中に、確認目的ではない構成変更・初期化・回復操作を行う
第3回まとめ｜現場での切り分けフロー
ストレージ関連の性能障害では、『容量』『I/O』『ハードウェア』を分けて考えることが重要です。最終的には、単に空き容量を作る、Busyを確認するだけでなく、なぜ容量が増えたのか、どの処理がI/Oを発生させたのかまで説明できる状態を目指します。
IBM i 運用・パフォーマンス障害切り分けチェックポイント（全4回）
第1回｜パフォーマンス低下発生時の初動切り分けについて
第2回｜メモリー・プールに起因するパフォーマンス低下の切り分けについて
第3回｜ストレージ逼迫・ディスク高負荷でIBM iが遅いときの切り分けについて
第4回｜パフォーマンス障害の事後分析と情報収集方法