2024.10.17

#23 メインフレームでのCPU移行シミュレーション事例

ES/1 MFシリーズ
メインフレーム
サイジング事例

CPUダウンサイジング時の業務影響を確認する

目次

開く

    今回はCPUダウンサイジング時のバッチ処理への影響有無について、メインフレーム向け性能管理ソフトウェア ES/1 NEO MFシリーズを活用したシミュレーション事例をご紹介します。

     

     

    背景と目的

    富士通ホストを運用されているお客様より、以下2点のご要望をいただきました。
     
    ・業務の一部オープン化に伴い、ホストにて稼働しているバッチジョブの一部を別ホストに移動した際に想定されるCPU使用負荷を算出したい。
    ・その際に現行CPUからのダウンサイジング（現行の70%）も予定しており、バッチ処理への影響有無を確認したい。
     

     

    前提条件

    ・移行先のホストは現行CPU能力の70%
    ・移行対象ジョブはバッチジョブ全体の40%
    ・対象データはES/1フラットファイルを使用
    ・対象期間はピーク日を含む1週間

     

     

    シミュレーションの実施

    シミュレーションでは、以下のように「現状確認→シミュレーション→詳細確認」の流れで実施します。

    ①現行ホストでCPU使用率を確認
    ②現行ホストでバッチ業務のCPU使用率を40%にして確認
    ③移行先ホストでCPU能力が70%になった場合のシミュレーション
    ④移行先ホストでCPU能力が70%を超えた箇所を詳細インターバルで確認
     
    まずは、現行ホストで、各業務がどれくらいの割合でCPUを使用しているかを確認します。
    面グラフの緑色の部分が今回移行対象のバッチ業務となります。

     

     

    図1_2
    図1_2

    図1：業務別CPU使用率(能力比：100％_移行ジョブの割合：100％)

     

     

    次に、現行ホストでバッチ業務のCPU使用を40%にした際の使用確認を行います。
    先程の面グラフから、緑色のバッチ業務の使用分を元の値の40%に減らします。
    また、水色の折れ線が先程の面グラフの最大値（現行CPUでのホスト全体の使用率）を表します。
     

     

    図2_2
    図2_2

    図2：業務別CPU使用率(能力比：100％_移行ジョブの割合：40％)

     

     

    次に、移行先ホストでCPU能力が70%になった場合のシミュレーションを行います。
    茶色の線が移行先ホストのCPU能力70%のライン、また、水色の折れ線が全業務の合計CPU使用率となります。
    水色の折れ線が茶色の折れ線を上回った分のCPU使用率は次のインターバルに持ち越してシミュレーションを行う事で、業務がどの程度後ろ倒しになるのかを確認しています。

    今回のケースですと、4月2日、7日にてCPU使用が抑えられる部分があります。

     

     

    図3：業務別CPU使用率(能力比：70％_移行ジョブの割合：40％)
    図3：業務別CPU使用率(能力比：70％_移行ジョブの割合：40％)

    図3：業務別CPU使用率(能力比：70％_移行ジョブの割合：40％)

     

     

    追加で4/2と4/7の詳細グラフにて影響度合いを確認します。
    4/2は9時前後のONLINEでの使用が多い時間帯で動作するバッチジョブでは処理が遅延する可能性が高いですが、午前中に処理するジョブ群としては現行と同等の12時に収束する予想となります。

     

     

    図4：シミュレーション後の業務別CPU使用率（4/2）
    図4：シミュレーション後の業務別CPU使用率（4/2）

    図4：シミュレーション後の業務別CPU使用率（4/2）

     

     

    また、4/7は23時頃にバッチジョブのCPU使用が抑えられますが、影響は軽微です。

     

     

    図5：シミュレーション後の業務別CPU使用率（4/7）
    図5：シミュレーション後の業務別CPU使用率（4/7）

    図5：シミュレーション後の業務別CPU使用率（4/7）

     

     

    シミュレーション結果

    バッチジョブの40%を現行CPU能力の70%のホストに移行した場合、CPU使用は現行での使用状況から大きな変化がなく、バッチ群の終了時間への影響は少ないと考えられます。

     

    CPU能力を使い切り、使用が抑えられる時間では一部のジョブで処理時間が長くなる可能性がありますが、バッチ群全体が大きく遅延するものではありません。

     

     

    まとめ

    念の為、現行の60%や50%のスペックでのシミュレーションも行い、一部のピーク時間帯で遅れが出る事から、今回は70%が安全ラインであるという事をお伝えしました。

    お客様からは「こちらでは現行の70%での移行を予定していたが、複数のシミュレーションパターンを実施いただいて分かりやすかった」とのお声をいただきました。

     

    今回ご紹介した内容が今後のパフォーマンス管理に少しでもお役に立てば幸いです。 

     

    執筆者

    Y.T.　

    営業技術本部 技術サービス統括部 技術サービス１部　

    お客様担当SEとして、製品の構築から活用方法までの一連のサポートを担当
    また、お客様環境にて性能問題が発生した際には、製品のアウトプットを利用し、問題解決に向けた調査／提案業務を実施

    ■経歴
    1999年　　入社
    2000年　　製品テスト等、ES/1シリーズの品質管理業務を担当
    2006年　　セキュリティ製品のお客様サポートを兼務
    2012年～　中部でのお客さまサポートを担当

    主にMF／CS製品を利用したシステムリソース情報からの性能管理サポートに従事
    近年は、上記に加えAPM製品を利用したユーザー体感レスポンスやアプリケーション視点での性能管理サポートにも従事

    関連記事