イントロダクション
ちょっと割と最近なのですが、驚いた事案がありましたのでご紹介します…
IBM i でパフォーマンスが悪い、というのでとあるベンダーさんがIBM i のパフォーマンス分析を実施してくださいました。
その結果（例）がこちらです・・
これは・・20世紀的なグラフと言いますか知らない人にはブロック崩しかインベーダーゲームに見えるかもしれません^^;
1980年代、クライアントPCもエクセルも無い時代（でもLOTUS 1-2-3はありました^^）、パフォーマンス分析結果をグラフ表示できたのは 画期的 でした。が今は2024年なんで35年くらいワープしているわけです。
ということで私が2024年的に上と同じデータを（多分同じ所要時間＝30分未満）で分析した結果例がこちらです。
いえ、私がすごいとかいう事は一切無くてただ、このツールの使い方を知っているか？だけの違いなんですね‥
このツールの名前を IBM Navigator for i と言います。という事で以下, Navigator for i のパフォーマンスツールのご紹介です。
Navigator for i パフォーマンス分析ツール とは
正確に言うとPerformance Data Investigator（パフォーマンス・データ・インベスティゲーター）という名前のツールです。
上の画面は（このような資料ではわかりやすいので）古いNavigator for i (2001番ポート接続）ですが、もちろん2002番の新しいNavigator for iでも同様に使えます。上図では画面左側に分析用の多様なリンクがあらかじめ用意されており、それをクリックするだけで、グラフ表示・数値表示ができます。
これ画期的でして、以前(20世紀W）はエキスパートが個別のパフォーマンスデータのカラムを漁って必要なデータを集計（エクセルその他で）してたんですね。まさに手練れの継承・システム化です。
Navigator for i の分析手順
どんな状態のシステムの何を調べたいかで変わってきますが、それが分かる方はここはスキップください。
パフォーマンス分析ステップ1 : ヘルス標識で当たりをつける
という事で初心者向けに説明しますと、コンピューターのリソースは大きく、CPU、メモリ、ディスクですから（これ以外に通信経路、ネットワークというのもありますが、まずはサーバー内という事で別に置いておきます）、そのどれが悪そうか（使用率が高い、IBM i で言うと"待機"という無駄な時間が発生しているか等を）当たりをつける必要があります。
ここで役立つのがヘルス標識です。
まず、システム・リソース・ヘルス標識でCPU、メモリ、ディスクのどこが閾値を超えているか確認します。(上図の右上のグラフ）
上図ではディスクに問題がある（赤、黄色で閾値越えのデータが多いので）と推察できます。
その次に、パフォーマンスの悪い装置（ここではディスク）の詳細を、ディスクヘルス標識で調べます。（上手の右下のグラフ）
すると、（上図が見づらいので下記に再掲）ディスクの使用率が閾値越えしていることがわかります。
※IBM i では一般にディスク使用率が70%超でレスポンスに悪影響が出始め、80%以上で明確、後は漸次劣化していきますが、99%のディスク使用率でも動くと言えば動きます。。（でも、やめてくださいね）。これは別でもすぐわかりますが、ディスクビジーやら、CPU（下図）が原因だとわかりにくいのですが、ヘルス標識でまずは可視化と当たりをつけることが出来ます。
※一口にCPUが悪い、と言っても具体的な悪さ具合は複数の指標があります。個々の説明は今回は割愛します・・また機会があれば・・
悪いと思われるリソースを深掘りする : CPU待機の状態（など）
やはりCPUが一番分かりやすいと思うのでCPUを例にあげて図示しますと、例えば下記のように CPUの待機の状態をグラフで調べることができます
待機とはこちらに簡単に触れていますが、、CPUの処理が効率的になされておらず無駄な（計算していない）時間が発生している状態です。この状態ではハードウェアリソースの追加、アプリケーション実行方法（実行管理上のチューニング）、アプリコードの修正など様々な問題改善法が考えられますが、何が有効か論理的な根拠データを提示するのが待機の状態調査、と言えます。
上図の例ですと、
・CPU使用率（赤い折れ線グラフ）が100%ではりついている時間帯が多いが、この時、実際にCPUで計算している時間的割合は実はあまり多くない（赤い棒グラフ）、代わりにCPUキューイングという待ち状態（紫の棒グラフ）が多発している、事が分かります。
・この例と違う症例としては、CPU使用率も高く、CPU計算時間も高い、という場合もあります。どちらになるかでその後の対処方法が変わってきます。
この先の分析方法はケースバイケースになってしまうと思いますが、ジョブ毎の処理（負荷）明細、その他詳細なデータが取得できているので、わからない場合はあれこれ、グラフを眺めてみる、というのも案外いい方法かもしれません。
パフォーマンスデータの取得～分析開始までの方法は？
・・記事が長くなってしまったのでこちらに書きました。