はじめに
IBM i 上にてパフォーマンスデータを収集した後に、収集したデータを展開し、分析する手順を書いていきます。
いつも手順がわからなくなってしまう自分に向けメモ要素が強いです。
パフォーマンス分析とは
システムのリソース使用状況やアプリケーションの動作状況を見ることで、CPU、メモリ、ディスクI/Oのリソース最適化や次期システムの容量計画に役立ちます。
またOSの標準機能で実施できます。
パフォーマンスデータの収集方法はこちらの記事を参考にしてください。
IBM i のパフォーマンスデータ収集の手順
収集データを取得する期間
1週間のデータを取得することが多いです。
その場合、突発的ピークがないことを確認し、CPU使用率が高い日をピーク日としてその1日の分析を行います。
業務ピーク日(月末など)のデータを収集し分析するといった、特定の1日のみを取得することもあります。
環境情報
①データを収集した環境
マシン：8202-E4C (IBM Power 720 Express)
OS：IBM i 7.1
②収集データを展開し、分析した環境
マシン：9105-41B (IBM Power S1014)
OS：IBM i 7.5
下記手順は全て②の環境で操作を行います。
パフォーマンスデータ分析の手順
収集データをアップロードするライブラリー/保管ファイルを作成する
①で収集したデータをアップロードするライブラリを作成します。
今回はBUNSEKIというライブラリを作成します。
CRTLIB LIB(BUNSEKI) TEXT('パフォーマンスデータ2024’)
次に作成したライブラリの中に保管ファイルを作成します。
作成する保管ファイルの名称は、①の環境で取得したファイル名PFRCOL .SAVFと同じにします。
CRTSAVF FILE(BUNSEKI/PFRCOL) TEXT('202408のデータ')
収集データをアップロード
FTPでも実施できますが、
筆者使用のMacはFTP非対応のため、SFTPでデータをアップロードしました。
IBM i 間でFTPにてデータをアップロードする場合は以下の記事を参照ください。
IBM i 間でのデータの転送方法
terminalで下記コマンドを実施しました。
sakurakoga@sknoair ~ % sftp sakura@ibmi75
Connected to ibmi75
put /Users/sakurakoga/PFRCOL.file /QSYS.LIB/BUNSEKI.LIB/PFRCOL.FILE
.SAVF形式はmacでは扱えないため、拡張子を.file形式に変換して送っています。
またterminalを使用する場合は、BUNSEKI.LIBのようにフルパスを指定する必要があります。
アップロードできたかを確かめます。
STRPDM→オプション1→BUNSEKIを指定→転送されたファイルを5番で表示
下記のようにある程度大きなデータサイズが表示できれば転送できています。
収集データをパフォーマンスデータに展開するライブラリの作成
パフォーマンスデータに展開するためのライブラリを作成します。
今回はTESTLIB名前にします。
CRTLIB LIB(TESTLIB) TEXT('xx様パフォーマンスデータ')
収集データの復元
取得されたパフォーマンスデータの保管もとライブラリを調べるため、下記コマンドを入力します。
DSPSAVF FILE(BUNSEKI/PFRCOL)
①はIBMDOCというライブラリにデータを収集していたことがわかります。
転送したファイルSAVF(BUNSEKI/PFRCOL)を、TESTLIBにて復元します。
RSTOBJ OBJ(*ALL) SAVLIB(IBMDOC) DEV(*SAVF) SAVF(BUNSEKI/PFRCOL) RSTLIB(TESTLIB)
パフォーマンスデータに展開する
復元した収集データを下記コマンドでパフォーマンスデータに展開します
CRTPFRDTA FROMMGTCOL(TESTLIB/*SELECT)
コマンドを入力するとオプション選択する画面が出るので、１で選択してENTER押します。
複数ある場合は1つずつ1を入力して実行します。
STRPDMでライブラリの中身を確認し、下記のようなファイルができていれば、展開完了です。
データを分析する
Navigator for iを用いてパフォーマンス分析を行います。
Navigator for iについては下記記事を参照ください。
IBM i駆け出し日記：新しいNavigator for iで現行システムの状況を見てみる
パフォーマンスデータ分析はNavigator for iのメニュバーの「データの調査」から行います。
収集ライブラリにパフォーマンスデータを展開したライブラリを選択します。
またパースペクティブからリソース使用状況を見ることができます。
以下はパフォーマンス分析を行う際に私が確認する項目です。
ヘルス標識
データの調査の収集ライブラリーのプルダウンメニューからヘルス標識にチェックを入れて、確認ができます。ヘルス標識から注意してみる箇所の値をつけることができます。
-
CPUヘルス標識
-
ディスクヘルス標識
-
メモリー・プール・ヘルス標識
| グラフ色 | 意味 |
|---|---|
| 緑色 | 推奨閾値より十分に低い時間帯 |
| 黄 | 推奨閾値と近い使用率の時間帯 |
| 赤 | 推奨閾値以上の使用率の時間帯 |
赤と黄色が出てきたところについて確認していきます。
今回のデータはこの4つが要注意そうです。
- CPU使用率
- 各ジョブに対するキューイングパーセント
- ディスク応答時間
- ディスクスペースの平均パーセント(ディスク使用率)
ちなみに、各項目にカーソルを合わせると閾値が確認できます。
収集サービス
リソース使用率
CPU使用率、ディスク使用率、ディスクのビジーパーセント(読み込みまたは書き込み要求の処理が発生している時間)の確認ができます。
下のチェックボックスを選択することで見たいグラフのみを表示できます。
下記の閾値を参考に、ピークを超えていないかを見ます。
| 項目 | 一般的な閾値 |
|---|---|
| CPU使用率 | 80% |
| ディスク使用率 | 70% |
| HDDのディスク・ビジーのパーセント | 30-40% |
CPU使用率においては深夜、早朝は大幅に、また日中もある時間帯では閾値である80%を超えていることが確認できます。
もしユーザーが直接触る(対話型のプログラムが稼働する)システムで、パフォーマンスが遅いと感じるようであればコアの増強をすべきであると言えます。
ディスク使用率においては、閾値の70%を超えています。
今後のデータ量の増え方にもよりますが、ディスク容量の増強をお勧めします。
CPU使用率および待機の概要
赤と黄色が出ていた、各ジョブに対するキューイングパーセントについて確認ができます。
- CPUキューイング時間：CPU内で処理待ちになっている時間
この時間が多いことは処理に対してプロセッサーのSMTが不足していることを示します。つまりコア不足です。
CPU使用率が高くないからといってコアを減らすとこの値が増える傾向にあります。(コアを減らすとSMTが減るから)
それ以外の項目についても確認します。
- ディスパッチされたCPU時間：CPU演算時間
- ディスク時間：ディスクI/O処理関連の時間
NVMeストレージ等で高速化することによって、グラフの時間は短縮されると推察されます。 - OS競合時間、ロック競合時間、不適格待機時間等は見られない。これはアプリケーション・運用設計が適切にできており、アプリケーション層での回避困難な処理待ちが発生してないことを表しています。
ディスク入出力の概要
ディスクI/Oに関連する値まとめです、グラフが多いので見たいものを絞って抽出するのをお勧めします。
- 平均ディスクの応答時間
閾値はヘルス標識によると閾値(黄色表示)は2ミリ秒、アクション閾値は6ミリ秒です。
グラフでは、左側に座標から合計2ミリ秒以上の応答に時間を要している時間帯が見受けられます。
このレンジの処理については、高速なNVMeストレージ等に移行することでディスク応答時の改善が期待できると考えられます。
その他必要がある時に見ているパースペクティブ/項目
-
各ディスク・ビジーのパーセントにおけるピーク時間のジョブ
リソース利用率において、ある一定時間だけディスクビジー率が突出していたらそのジョブを突き止めるために確認しています。
ジョブ名を見て、そのジョブがバッチではなく対話型だった場合はディスクI/O改善のためディスクの本数を増やす必要があります。 -
メモリのページング数
メモリのヘルス標識に黄色/赤がある際に確認しています。
ページングとは、物理メモリに収まりきらないデータをハードディスクなどの補助記憶装置に一時的に移すことなので、ページング数が多いということはメモリ容量不足の可能性が高いです。
Navigator for i では「メモリ不在の数/1秒あたりの障害数」と表現されています。
1秒あたりの障害数という項目(閾値は1コアあたり100以下)を確認し、次にプールごとのページング数をみます。
IBM i にはプールが4つありますが、その中でもマシン・プール(プール番号001)に注目して確認しています。(閾値は15-20件以下)