目次

３．１　CPU統合における問題点

３．２　CPU能力積上げ方式

３．３　CPU統合後の処理時間

３．４　事例～不安定な処理時間

３．１　CPU統合における問題点

　複数のCPUを保有しているお客様では、仮想化技術を使ったCPU統合を進めています。メインフレームでの仮想化技術(AVM)には20年近い歴史がありますが、性能に関する議論は浅く、次のような問題が発生しています。

A、CPU統合時、最適なCPUを選定する見積り手法が確立されていない。
B、CPU統合後、バッチジョブの処理時間が予想以上にばらつく。
C、統合前に比べ遅くなる。

　Aについては、既存のCPU能力をベースにした「CPU能力積上げ方式」でCPUを選定しているケースが見受けられます。この方法について考察します。
　Bについては、不安定な処理時間を生み出すロジックを解明しましたので紹介します。
　Cについては様々なケースが考えられます。同じプログラムでもAVM化によりCPU時間やI/O時間が延びることがあります。本件は性能トラブルであり今回は割愛します。

 

３．２　CPU能力積上げ方式

３．３　CPU統合後の処理時間

◆解説
　AVMの設定にもよりますが、10～15分前後で推移します。「前後」とは第１回の問１で説明したバラツキです。ここでは10～15分の幅について説明します。
　処理時間の内訳は以下のようになります。問４ではI/O時間が不変かつ単体処理時間なのでCPU待ち時間＝０と考えます。
　　旧：処理時間＝I/O時間＋CPU待ち時間(0)＋CPU時間
　　新：処理時間＝I/O時間＋CPU待ち時間(0)＋CPU時間＋他VM待ち時間＋AVM走行時間

　旧システムでのCPU時間が新システムでどのように変わるかを図６で説明します。
　単体CPU性能が向上することにより、CPU時間は短くなり、新たに他VM待ち時間が発生します。他VM待ち時間は、AVMのLOGICALモードでは固定化し、AUTOMATICモードでは変動します。

図６　AVMによる待ち時間の考え方

　１号機で単体処理時間が15分（CPU時間10分、I/O時間５分）だったバッチジョブを新システム（AUTOMATICモード）で実行すると、図７のように10分弱～15分で変動します。重要な点は、単体での処理性能が他VMの稼動状況に左右されるということです。

 

図７　バッチジョブの処理時間の推移

注）待ちに含まれるAVM走行時間(0.4分)は、他VMが稼動していないと小さくなるため図７の最短モデルでは省略しています。

 

 

３．４　事例～不安定な処理時間

　本番機と開発機を統合した事例を紹介します。移行後の本番VMでのバッチ処理の処理時間に注目してください。
システムの概要

ジョブの稼動状況

　日中に実行されたバッチジョブの稼動状況を表２に示します。バッチＡはI/O中心の処理、バッチＢはCPU中心の処理です。

表２　バッチジョブＡ、Ｂの稼動状況

解説

バッチＡについて（I/Oバウンド処理）

処理時間が短縮したのは、DASD性能の向上による効果。
移行後の処理時間に32分の差があるのは、CPU待ちによる影響。

バッチＢについて（CPUバウンド処理）

移行後の1:21:43が速すぎる。（問４での最速時間が出たケース）
移行後の処理時間1時間13分の差は、CPU待ちと他VM待ちによる影響。

特に、CPU統合直後の速すぎる性能には注意が必要です。

 

　以上、３回にわたってCPUリプレースの考え方を紹介しました。CPU使用率100%でも正常に稼動する、CPUをダウングレードできるのがメインフレームの強みだと考えています。適切なCPUを選択するには、お客様自身の目を光らせることが重要です。