筆者が1992年に書いた性能評価に関する論文があるが、15年後の今でもほとんどがそのまま使える内容である。これは、OSやミドルウェアの基本部は変わっていないことを意味している。それでは、５年前のノウハウで性能評価ができるかというと大きな落とし穴がある。ハードウェアの特性の変化である。今回は昔の常識が通用しなくなった事例を２つ紹介し、その本質を検証していきたい。

目次

事例２～SORTがCPUを多量に使うのは本当に仕様か？

事例３～メインフレームは本当に多重処理に強いのか？

事例２～SORTがCPUを多量に使うのは本当に仕様か？

　CPUを多く使っているジョブを調査していたところ、あるSORT処理のCPU時間が大きいことが判明した。処理内容は約600MBの単純SORTであり、処理時間は150～200秒、CPU時間が77～86秒であった。処理能力（＝データ量／処理時間）は3～4MB/Sで妥当な数値である。

■問題点
CPU占有率（＝CPU時間／処理時間）を算出すると41～51%となる。 CPUは一世代前のハイエンド機GS21モデル600であり、CPU占有率40%超はCPUループに近い状態である。 注）SORTはデータの並び方によって、CPU時間は大きく変化する。

■原因
SORTのメモリアクセスでCPUを多量に使っている。 メーカの見解はSORTの仕様であるため、メモリアクセス方法の妥当性については調査できていない。

■対処
SORTが使えるメモリを少なくする。省略値で拡張REGIONに8MB確保していたメモリをとらないようにJCLでPARM=’AESIZE(0K)’と設定した。

■成果
図２に示す通り、処理時間（ELAPSED TIME）はほとんど変わらず、CPU時間（CPUTIME）は約60%削減した。なお、1/31は月末処理のためシステムの負荷が高く処理時間が遅延している。

図２　SORTの処理時間とCPU時間の推移

■考察
（本質） CPUの性能向上に比べメモリアクセスは速くなっていないため、CPUとメモリ間のキャッシュメモリサイズを大きくして調整している。そのため、キャッシュミスしやすい処理（多量のデータアクセス等）はCPU時間が増える傾向がある。 DASDの飛躍的な性能向上により、メモリサーチよりもDASDアクセスの方が効率よく処理できるケースが出てきている。 データベース用の大きなバッファも注意が必要である。

事例３～メインフレームは本当に多重処理に強いのか？

２台のCPUをAVMを使って１台に統合したところ、バッチ処理は速くなったが、時々極端に遅くなるので調査したいとの依頼を頂いた。（表２）

表２　CPU統合前後の比較

■問題点
データの処理件数はほぼ同じ（EXCP回数より）と仮定すると、CPU統合後の処理時間に1.9倍･･･①、CPU時間に1.2倍･･･②の差がある。

■原因
システムの稼動状況を分析して性能モデルを作成し、処理時間のシミュレーションを行ったところ図３のような結果となった。バッチジョブが３多重になるとCPU待ち時間の増加により処理時間は1.7倍になることがわかった。
また、CPU時間の延びは、AVMのオーバヘッドやVM間のキャッシュメモリの競合等が考えられる。
処理時間が1.9倍になるのは妥当な結果であった。

■対処
重要な１ジョブだけCPUプライオリティを上げれば、CPU待ち時間による影響は受けにくくなり処理時間は安定する。しかし、他のジョブのCPU待ち時間は増大するため積極的には推奨はできない。
中規模クラスのメインフレームは、バッチの多重度が上がれば処理時間は図３のように一次関数的に遅くなることを認識して運用する必要がある。

■考察（本質）

• CPU性能に比べI/O性能が非常に向上したため、CPUとI/Oの処理バランスが変わってきた。I/Oバウンドだと思っている処理も実際はCPU依存で動いていることが多い。
• システム構成によっては、処理時間が２倍、３倍と遅延するケースも現実にある。
• CPUレベルアップやCPU統合の直後は負荷が軽く（多重度が低く）、「速すぎる性能」が出てしまうことがあり、運用には十分注意を払う必要がある。