１．はじめに
今回IBM i RiSING に参加し課題をとして成果物を作成することになり、自分自身がどのような記事があったら日常業務で役立つかを考えた。その結果、IBM i 運用時に起きるパフォーマンス低下の確認方法のマニュアルのようなものがあれば、都度方法を調べることなく迅速に対処できると考え、本記事の作成に至った。
本記事ではどんなコマンドで何ができるかを生成AIに問いチェックリスト形式で出力したものを確認していく。生成AIのIBM i に関する情報の確度と、コマンドを用いたパフォーマンス確認の有用性を併せて見て行きたいと思う。ただし、時間の都合上チェックリストの「パフォーマンス低下時の対応策」については検証しない。
なお、実行OS環境はV7R2である。現行の最新バージョンはV7R6なのでかなり古い環境であること、また筆者は日常業務ではほぼ5250エミュレータに触れることのない、かなりの初心者であることについてはご容赦願いたい。
基本的には自身の学びのための記事ではあるが、この記事を見て少しでも役立つと冥利に尽きる。
２．生成AI作成のチェックリスト
| # | 確認項目 | 詳細な確認方法 | パフォーマンス低下時の対応策 |
|---|---|---|---|
| 1 | CPU使用率 |
WRKSYSSTSで「% CPU used」や「Average CPU」を確認 |
1. WRKACTJOBでCPU使用率の高いジョブを確認2. ENDJOB JOB(XXXXXX)で不要ジョブを停止3. WRKJOBSCDEでジョブスケジュールを見直し |
| 2 | メモリ使用率 |
WRKSYSSTSで「Main Storage Size」「% DB Faults」を確認 |
1. WRKACTJOBでメモリ使用率の高いジョブを確認2. DSPJOB JOB(XXXXXX)でジョブ詳細を確認し、メモリリークの可能性を調査3. IBM i Navigatorで物理構成を確認し、メモリ増設を検討 |
| 3 | ディスク使用率とI/O待ち |
WRKDSKSTSでディスク使用率とI/O待ち時間を確認 |
1. WRKDSKSTSで高負荷ディスクを特定2. RCLSTGでストレージ再編成（※メンテナンス時間に実施）3. DLTF FILE(...)で不要ファイル削除 |
| 4 | ジョブ数と状態 |
WRKACTJOBでジョブ数、CPU使用率、待機状態（DEQW、MSGWなど）を確認 |
1. WRKACTJOBで待機状態のジョブを確認2. ENDJOB JOB(XXXXXX)で不要ジョブを終了3. CHGJOB JOB(XXXXXX) RUNPTY(n)で優先度調整 |
| 5 | 通信待ち（ネットワーク） |
NETSTATで接続状況、WRKTCPSTSでTCP/IPステータスを確認 |
1. NETSTAT OPTION(*CNN)で異常接続を確認2. ENDTCPIFCで問題のあるインターフェースを停止3. CHGTCPAでTCP/IP設定を見直し |
| 6 | データベースロック |
WRKOBJLCK OBJ(...) OBJTYPE(*FILE)でロック状態を確認 |
1. WRKOBJLCKでロック対象ジョブを確認2. ENDJOB JOB(XXXXXX)またはENDJOBABNで強制終了3. アプリケーション側でトランザクション分割を検討 |
| 7 | ジョブキューの滞留 |
WRKJOBQでジョブキューの状態を確認 |
1. WRKJOBQで滞留ジョブを確認2. SBMJOB CMD(...) JOBQ(...)で手動実行3. CHGJOBQ JOBQ(...) MAXACT(n)で同時実行数を調整 |
| 8 | サブシステムの負荷 |
WRKSBSで各サブシステムのジョブ数とCPU使用率を確認 |
1. WRKSBSで負荷の高いサブシステムを特定2. MOVJOB JOB(XXXXXX) SBS(QINTER)でジョブ移動3. CHGSBSD SBSD(...)で構成見直し |
| 9 | メッセージ待ちジョブ |
WRKMSGWでMSGW状態のジョブを確認 |
1. WRKMSGWで対象ジョブを確認2. DSPMSG MSGQ(QSYSOPR)でメッセージ内容を確認3. CHGMSGQ MSGQ(QSYSOPR) DLVRY(*BREAK)で即時通知設定 |
| 10 | パフォーマンスデータ収集 | Performance Tools（PM/400）やNavigator for iで収集 | 1. STRPFRCOLでパフォーマンスデータ収集開始2. ENDPFRCOLで収集終了3. ANZPRFCOLで分析し、傾向を把握して改善策を立案 |
３．それぞれの項目の検証
実際にチェックリスト各項目のコマンドを実行する。
３－１．CPU使用率
CPU使用率が表示されていないが、F21で援助レベルを「中間」以上に設定することで表示されるようになる。
・援助レベル「中間」
・援助レベル「拡張」
３－２．メモリ使用率
合計メモリサイズが表示されると生成AI作成のチェックリストでは示唆されているが、実際にWRKSYSSTSの実行結果画面上にはそのような項目はなかった。
しかし、以下の各システムプールの「プールサイズM」を合算することで合計メモリサイズを算出できる。
メモリ使用率についても画面上には表示されていないが、メモリが不足しているか否かは推測することができる。
赤枠部のフォールト率が高いとメモリが不足している可能性が高いとのこと。
３－３．ディスク使用率とI/O待ち
以下がWRKDSKSTSの実行結果である。
ディスクの使用率(%USED)は表示されているが、I/O待ち時間に関する記述はない。
調べたところ、%BUSY という項目が「ディスクがI/O処理でビジー状態だった時間の割合」を示しており、I/O待ち時間の間接的な指標になるということがわかった。
この値が高い場合、ディスクが頻繁にアクセスされており、I/O待ちが発生している可能性が高いと判断できる。しかし直接的な「I/O待ち時間」ではなく、負荷の間接的な指標であることには注意が必要である。
３－４．ジョブ数と状態
WRKACTJOBを実行すると以下のような結果が得られる。
この項については生成AIが作成したチェックリストの通りの項目が画面上に表示されていた。弊社においては「状況」がMSGWになり止まってしまっているジョブが度々出現するので、この項目は注視したい。
３－５．通信待ち（ネットワーク）
NETSTATまたはWRKTCPSTSコマンドを実行する。どちらを実行しても同じ画面に遷移するため、好きな方を使えば良い。NETSTATコマンドは他OSでもよく使うコマンドなので、なじみのある方は少なくないと思う。
上記コマンドをオプションなしで実行すると以下のような選択画面が表示される。
一般的に利用されているのはIPv4かと思うので、基本的には1~3の内容を確認することになる。1~3の中でも1,2については基本的な設定を行うメニューとなるため、基本的には3の接続状況の処理を見ることになる。メニュー選択画面を介さずに3のメニューを起動するには、NETSTAT *CNNを実行すれば良い。
正常に通信が行われている場合は状態が「確立済み」となるが、異常が生じている場合は遅延や切断がないか確認を行う。
３－６．データベースロック
WRKOBJLCKコマンドを実行し、オブジェクトのロック状況を確認する。AI作成のチェックリストでもオプションが明記されているように、このコマンドはオプションで確認するオブジェクトの指定が必須となる。
オブジェクトの指定を行うと以下のような画面が表示される。
占有ロックが長時間行われるとデータベースへの読み書きが行えなくなるほか、競合が多いとパフォーマンスに影響する。
３－７．ジョブキューの滞留
WRKJOBQでジョブキューの状況を表示する。
ジョブキューに滞留しているジョブがないかを確認する。状況がHLDやDMGとなっている場合はジョブの詳細を確認する必要がある。
３－８．サブシステムの負荷
WRKSBSを実行。
この画面でF11キーを押下すると各サブシステムのジョブ数とCPU使用率が表示される旨がAI作成のチェックリストには記載されていた。しかし、実際にはジョブ数のみしか表示されず、CPU使用率は表示されなかった。
CPU使用率は残念ながら確認出来なかったが、他のコマンドと組み合わせることで間接的に負荷状況を把握することはできる。
WRKSBSを実行した直後に表示される画面に「サブシステム・プール」という欄がある。
ひとつのサブシステムにつき最大10個まで使用するプールを指定することができるのだが、この欄はそれを示している。ややこしいが画像の場合、サブシステム・プールID１にはプールID２のプールが指定されているということになる。
ここで指定されているプールID２に紐づくプールは、WRKSHRPOOLコマンドで確認することができる。
この画面ではさらにメモリのサイズや最大活動ジョブ数を確認出来るため、さきほどのWRKSBSで確認出来る合計記憶域や活動ジョブ数と合わせ負荷状況を把握できる。
３－９．メッセージ待ちジョブ
AIが作成したチェックリストにはWRKMSGWを実行するよう記載されていたが、そのようなコマンドは調べた限りでは実在しなかった。
ここにきて生成AIの大きな誤りが露呈する形となった。
３－１０．パフォーマンスデータ収集
諸事情によりNavigator for i を使用できないため、生成AIにチェックリストの作成を指示した際に「コマンドで確認できる」ことを条件としていたのだが、本項目はコマンド以外のツールが必要となってしまっている。確認のしようがないため本項はスキップする。
４．修正版チェックリスト
検証結果を基に修正や削除を行ったチェックリストは以下の通り。
| # | 確認項目 | 詳細な確認方法 | パフォーマンス低下時の対応策 |
|---|---|---|---|
| 1 | CPU使用率 |
WRKSYSSTSで「% CPU used」や「Average CPU」を確認 |
1. WRKACTJOBでCPU使用率の高いジョブを確認2. ENDJOB JOB(XXXXXX)で不要ジョブを停止3. WRKJOBSCDEでジョブスケジュールを見直し |
| 2 | メモリ使用率 |
WRKSYSSTSで |
1. WRKACTJOBでメモリ使用率の高いジョブを確認2. DSPJOB JOB(XXXXXX)でジョブ詳細を確認し、メモリリークの可能性を調査3. IBM i Navigatorで物理構成を確認し、メモリ増設を検討 |
| 3 | ディスク使用率とI/O待ち |
WRKDSKSTSでディスク使用率と |
1. WRKDSKSTSで高負荷ディスクを特定2. RCLSTGでストレージ再編成（※メンテナンス時間に実施）3. DLTF FILE(...)で不要ファイル削除 |
| 4 | ジョブ数と状態 |
WRKACTJOBでジョブ数、CPU使用率、待機状態（DEQW、MSGWなど）を確認 |
1. WRKACTJOBで待機状態のジョブを確認2. ENDJOB JOB(XXXXXX)で不要ジョブを終了3. CHGJOB JOB(XXXXXX) RUNPTY(n)で優先度調整 |
| 5 | 通信待ち（ネットワーク） |
NETSTATまたはWRKTCPSTS で接続状況、 WRKTCPSTSで |
1. NETSTAT OPTION(*CNN)で異常接続を確認2. ENDTCPIFCで問題のあるインターフェースを停止3. CHGTCPAでTCP/IP設定を見直し |
| 6 | データベースロック |
WRKOBJLCK OBJ(...) OBJTYPE(*FILE)でロック状態を確認 |
1. WRKOBJLCKでロック対象ジョブを確認2. ENDJOB JOB(XXXXXX)またはENDJOBABNで強制終了3. アプリケーション側でトランザクション分割を検討 |
| 7 | ジョブキューの滞留 |
WRKJOBQでジョブキューの状態を確認 |
1. WRKJOBQで滞留ジョブを確認2. SBMJOB CMD(...) JOBQ(...)で手動実行3. CHGJOBQ JOBQ(...) MAXACT(n)で同時実行数を調整 |
| 8 | サブシステムの負荷 |
WRKSBSとWRKSHRPOOL で各サブシステムのジョブ数と |
1. WRKSBSで負荷の高いサブシステムを特定2. MOVJOB JOB(XXXXXX) SBS(QINTER)でジョブ移動3. CHGSBSD SBSD(...)で構成見直し |
WRKMSGWでMSGW状態のジョブを確認 |
WRKMSGWで対象ジョブを確認2. DSPMSG MSGQ(QSYSOPR)でメッセージ内容を確認3. CHGMSGQ MSGQ(QSYSOPR) DLVRY(*BREAK)で即時通知設定 |
||
STRPFRCOLでパフォーマンスデータ収集開始2. ENDPFRCOLで収集終了3. ANZPRFCOLで分析し、傾向を把握して改善策を立案 |
５．おわりに
生成AIにチェックリストを作成させ、それを基にパフォーマンス情報の確認方法を学ぶ、という切り口でここまで進めてきた。
チェックリストの内容を順に確認していくことで、IBM i を運用する上で何を確認すれば良いのか少し勘どころがわかった。
今までほとんどIBM i に触れてこなかった私にとって、生成AIがなければどんなコマンドを使用してパフォーマンス情報を取得すれば良いかここまで容易に知ることはできなかった。一方で、虚偽の内容をあたかも真実かのように回答する生成AIの欠点に振り回されもした。
最終的なチェックリストは私のようなIBM i 初心者には少なからず役立つのではないかと思う。
当記事の著作権はIBMに帰属します。
詳細はこちらを参照ください。