はじめに
IBM i RiSING (若手技術者コミュニティ）の一環として、「IBM i の運用」をテーマに学習を行いました。その中で、日々の運用やパフォーマンス障害発生時に、「何を確認するか」「どのコマンドを使用するか」「次に何を見るか」を整理し、確認方法や切り分け手順を初学者向けに4つの記事としてまとめました。本ページは、各記事への目次ページとなります。
記事一覧
-
第1回｜パフォーマンス低下発生時の初動切り分けについて
WRKSYSSTS、WRKACTJOBなどを使用し、パフォーマンス低下発生時に最初に確認する内容をまとめています。
URL： https://qiita.com/e_kuwabara/items/f426dc7b1dc8f68c3f82 -
第2回｜メモリー・プールに起因するパフォーマンス低下の切り分けについて
メモリー・プール、不在(Fault)、実行不適格（INEL）などを確認する方法をまとめています。
URL： https://qiita.com/e_kuwabara/items/1aeb69bb06e23928aa22 -
第3回｜ストレージ逼迫・ディスク高負荷でIBM iが遅いときの切り分けについて
システムASPやディスクI/Oを確認し、ストレージ容量やディスク高負荷による性能低下を切り分ける方法をまとめています。
URL： https://qiita.com/e_kuwabara/items/af8cf537ff88567103c8 -
第4回｜パフォーマンス障害の事後分析と情報収集方法
Collection Services、WRKPRB、STRSSTなどを使用し、過去に発生した障害を調査する方法をまとめています。
URL： https://qiita.com/e_kuwabara/items/3d9737954fe3a786d7e5
4記事共通｜性能障害対応コマンド一覧
| 観点 | コマンド | 確認内容 | 考え方 |
|---|---|---|---|
| 現象特定 | ― | 発生時刻、範囲、対象、通常との差 | 最初に問い合わせ内容を具体化・数値化する |
| 全体 | WRKSYSSTS |
CPU、ASP、プール、ジョブ数等 | 単独の数値ではなく平常時との差（変化）を重視する |
| ジョブ確認 | WRKACTJOB |
CPU、Status(状況)、経過時間等 | 高CPUジョブだけでなく待ち状態（LCKW等）も確認する |
| 絞り込み |
WRKSBSJOB / WRKUSRJOB
|
サブシステム単位のジョブ一覧、ユーザー単位のジョブ一覧等 | 全ジョブを見続けず対象業務やユーザーに絞り込む |
| ジョブ詳細 | WRKJOB |
ジョブログ、ロック、ファイル等 | 原因候補ジョブの内部挙動やエラーメッセージを深掘りする |
| ロック確認 | WRKOBJLCK |
ユーザー、状況等 | 待たされている側（LCKW）だけでなく保持側を追う |
| メモリー |
WRKSYSSTS / WRKSHRPOOL
|
不在(Fault)、活動→不適格(Active->Inel)実行、最大活動(Max Active)等 | 不在(Fault)増加とINEL発生を組み合わせ、単独値で安易に設定変更しない |
| ディスク | WRKDSKSTS |
Busy、I/O、偏り等 | ASP容量（保存領域）とディスクI/O（処理負荷）を分けて考える |
| 詳細活動 | WRKSYSACT |
CPU、I/O、SQL CPU | 初動切り分け後のリアルタイム詳細分析に使用する |
| メッセージ | DSPMSG QSYSOPR |
障害時刻前後 | 障害時刻前後のシステム・装置・通信関連メッセージを確認する |
| 問題ログ | WRKPRB |
問題ログ、問題ID等 | ソフトウェア側で説明できない場合のハードウェア側の兆候を確認する |
| 保守ツール | STRSST |
PAL、リソース、Disk構成等 | 表示・参照を基本とし、構成変更や回復操作は行わない |
| 過去性能 | Collection Services |
障害時と平常時 | 現在正常に戻っている障害の事後分析・平常時との比較を行う |
まとめ
今回、RiSINGの活動を通して、IBM iの運用について学習し、初学者向けのチェックポイントとしてCLコマンドを中心に整理しました。
学習を進める中で、CLコマンドの使い方を知るだけではなく、
「現象 → 仮説 → 確認コマンド → 判断 → 次の一手」
という流れで考えることが重要だと学びました。
また、性能障害の切り分けにおいては、現在の状態だけで判断するのではなく、平常時の状態と比較し、どのような変化が生じているかを確認することも重要です。
本連載が、IBM iの運用を学び始めた方にとって、障害発生時に「まず何を確認すべきか」を考える際の一助となれば幸いです。