はじめに
性能障害の問い合わせで厄介なのが、『さっきまで遅かったけれど、今は戻っています』というケースです。現在の WRKSYSSTS や WRKACTJOB を見ても正常で、原因が分からないまま『様子見』になってしまうことがあります。
このような障害を調査するためには、現在値を見るCLコマンドだけでなく、過去の性能データを残す仕組みが必要です。本記事ではCollection Servicesを中心に、平常時のベースライン、問題ログ、STRSSTまで含めて、事後調査につながる運用を整理します。
1. 現在値と過去データを使い分ける
| 確認したいもの | 主な手段 |
|---|---|
| 現在のシステム全体 | WRKSYSSTS |
| 現在のジョブ |
WRKACTJOB / WRKJOB
|
| 現在のディスク | WRKDSKSTS |
| 現在の詳細活動 | WRKSYSACT |
| 過去の性能 |
Collection Services（GO PERFORM） |
| 問題記録 | WRKPRB |
| ハードウェア寄りのログ |
STRSST → プロダクト活動ログ(Product activity log) |
現在の画面が正常だからといって、障害発生時も正常だったとは限りません。現在発生中ならリアルタイム系のコマンド、復旧済みなら収集済みの性能データへ切り替える、という判断が重要です。
2. Collection Servicesを継続して収集する（GO PERFORM）
CHKPFRCOL
CFGPFRCOL + F4
STRPFRCOL
ENDPFRCOL
CHKPFRCOL で収集状態を確認し、CFGPFRCOL で設定を確認します。障害が発生してから STRPFRCOL を開始しても、発生前の状態は取り戻せません。そのため、性能障害に備えるという意味では『普段から収集していること』が重要です。
収集間隔や保持方針は、システム規模、ディスク容量、分析要件に合わせて設計します。重要なのは、ピーク時間帯を含む平常時データと、障害時データを比較できる状態にすることです。
3. CRTPFRDTAで分析用データを作る
CRTPFRDTA FROMMGTCOL(ライブラリー/収集オブジェクト)
CRTPFRDTA を実行することで、蓄積された収集オブジェクトから分析用のパフォーマンス・データベース・ファイルが生成されます。
生成されたデータベース・ファイルは、指定ライブラリー内に QAPM から始まるファイル群として格納されます。正常に作成されたかの存在確認は、以下のCLコマンドで実施します。
WRKOBJ OBJ(ライブラリー名/QAPM*) OBJTYPE(*FILE)
【確認の手順】
Collection Services ➔ CRTPFRDTA ➔ WRKOBJ ➔ GO PERFORM（7: 画面確認 / 3: レポート出力）➔ 平常時データとの比較検証
- 印刷出力では、システム全体、コンポーネント構成、ジョブ活動、メモリー・プール、ディスクリソースなど、分析目的に適合した形式を選択します。
- 対話画面での参照ではなく、スプール出力や紙面として分析情報を残したい場合は、
GO PERFORM画面から 3「パフォーマンス・レポートの印刷」を実行します。 - 提示されたメンバー一覧の中から、障害発生時間帯に対応するデータを選択し、CPU消費、ジョブ挙動、プール状況、ディスクI/O等の数値を比較・調査します。
-
GO PERFORM画面から 7「パフォーマンス・データの表示」に進むことで、作成済みの性能データを対話画面上でダイレクトに調査できます。 - データベース・ファイルの作成を完了した後は、5250画面のコマンドラインより
GO PERFORMを起動して次の調査フェーズへ進みます。
4. ベースラインを作る
性能障害の判断を難しくする原因の一つが、『普段の値を知らない』ことです。平常時のCPU、システム ASP、不在(Fault)、活動ジョブ、% 使用中などを記録しておくと、問い合わせ時に異常な変化を素早く見つけられます。
| 項目 | 平常時例 | 障害時に見ること |
|---|---|---|
| CPU | 25～40% | 通常範囲から外れているか |
| システム ASP | 68～70% | 急増していないか |
| DB 不在(Fault) | 100～300/sec | 平常時比で増えていないか |
| Active→INEL | ほぼ0 | 継続的に増えていないか |
| 活動ジョブ | 220～250 | ジョブ数が急増していないか |
| % 使用中 | 20～30% | 全体または一部装置が突出していないか |
ここで示した数値は例です。自分たちのIBM i環境の通常値を蓄積し、『このシステムにとっての正常』を作ることが重要です。
5. 日次チェックを性能障害調査に使える形にする
| 項目 | コマンド | 記録例 |
|---|---|---|
| システム状態 | WRKSYSSTS |
CPU 31%、ASP 69.2% |
| ジョブ状態 | WRKACTJOB |
MSGW 0、LCKW 0、INEL 0 |
| サブシステム | WRKSBSSTS |
主要サブシステム正常 |
| Disk | WRKDSKSTS |
最大Busy 28% |
| QSYSOPR | DSPMSG QSYSOPR |
重要メッセージなし |
| 問題ログ | WRKPRB |
新規問題なし |
| 性能収集 | CHKPFRCOL |
収集中 |
チェック結果を○／×だけで残すと、後から比較できません。CPU31%、ASP69.2%のように実数を残すことで、数週間後の障害時に『いつから変化したか』を追いやすくなります。
6. WRKPRBで問題ログを見る
WRKPRB
性能問題に見えても、装置やハードウェアに関連する問題記録が作成されている場合があります。QSYSOPR メッセージだけで原因が分からず、ディスクやアダプターなどが疑わしい場合は WRKPRB も確認します。
7. STRSSTとは何か
STRSST
STRSST はシステム保守ツール（SST）を開始するためのCLコマンドです。通常の運用コマンドよりも、ハードウェアやライセンス内蔵コードに近い情報へアクセスできます。性能障害が起きたから最初に実行するコマンドではなく、通常の切り分けでハードウェア側の疑いが出た後に使う位置付けです。
【調査の流れ】
WRKSYSSTS → WRKACTJOB → WRKJOB → WRKDSKSTS → Collection Services
│
Hardware側の疑い
│
WRKPRB → STRSST
SSTへのサインオンではサービス・ツール側の認証が関係します。また、通常のIBM iユーザープロファイル側でも必要な権限を持つ運用者が扱うことを前提にします。
8. プロダクト活動ログ(Product activity log)（PAL）を見る
STRSST
↓
保守ツールの開始(Start a service tool)
↓
プロダクト活動ログ(Product activity log)
プロダクト活動ログ(Product activity log)には、ハードウェアやLICなどに関連する情報が記録されます。性能低下時刻と同じ時間帯に、特定リソースのエントリーが繰り返されていないかを確認します。
ログに記録があるだけでハードウェア故障と断定するのではなく、Collection ServicesのI/O増加、WRKDSKSTS の偏り、QSYSOPR メッセージ、問題ログなどと時刻を合わせて判断します。
9. ログの分析(Analyze log)とハードウェア保守管理機能(Hardware service manager)
STRSST → 保守ツールの開始(Start a service tool) → プロダクト活動ログ(Product activity log) → ログの分析(Analyze log)
ログの分析(Analyze log)では、同じリソースや同じ種類のエントリーが繰り返されていないかを見ることで、断続的なハードウェア問題の手掛かりを探せます。
STRSST → 保守ツールの開始(Start a service tool) → ハードウェア保守管理機能(Hardware service manager)
ハードウェア保守管理機能(Hardware service manager)では、システムが認識しているDisk、Adapter、I/O リソースなどを確認できます。WRKDSKSTS で一部装置に偏りがあり、PALにも関連しそうな記録がある場合などに、リソースをさらに確認するための次段階として利用します。
10. STRSST使用時の注意点
SSTには表示・参照だけでなく、構成変更、初期化、回復操作などシステムやデータに大きな影響を与える機能もあります。性能障害の調査目的では、表示・ログ参照を基本とし、変更系の操作は正式な手順書、管理者、IBMサポート等の指示なしに実施しないようにします。
特に『空き容量を増やしたい』『ディスクが怪しい』という理由だけで、SST上から構成変更を行うことは避けます。SSTは強力なサービスツールであるため、確認範囲を明確にして利用することが重要です。
第4回まとめ
性能障害をその場だけで終わらせないためには、平常時から性能データを残し、現在値・過去データ・問題ログ・PALを時刻で関連付けることが重要です。Collection Servicesは『障害が起きたら使うもの』ではなく、『障害が起きる前から動かしておくもの』と考えると分かりやすいです。
IBM i 運用・パフォーマンス障害切り分けチェックポイント（全4回）
第1回｜パフォーマンス低下発生時の初動切り分けについて
第2回｜メモリー・プールに起因するパフォーマンス低下の切り分けについて
第3回｜ストレージ逼迫・ディスク高負荷でIBM iが遅いときの切り分けについて
第4回｜パフォーマンス障害の事後分析と情報収集方法