目次

はじめに

メインフレーム上での問題点

事例１～夜間バッチジョブの処理時間短縮

図１　夜間CPU使用率の推移

表１　10万件のデータでテストした結果

はじめに

　2007年5月現在、富士通のメインフレーム（GS、PRIMEFORCE）は3,000台以上稼動している。富士通は、昨年GS21の最上位モデルを発表し、2009年度後半以降には次機種も計画している。基幹IAサーバPRIMEQUEST上でメインフレームのOSであるXSPを動作させることも先日発表した（出荷は2008年度上期中）。5年前に比べ、メインフレームにも少し力を戻してきた感がある。 お客様にとって2007～2008年の大イベントは日本版SOX法対応であり、メインフレーム上で構築した基幹システムを改めて見直す時期にきている。

メインフレーム上での問題点

メインフレームはよく堅牢・高信頼・高品質といった言葉で表現される。これは、本体系のハードウェアと基本OSのコアの部分ついては正しいが、システム全体から見ると疑問が残る。また、高性能、コストパフォーマンスといった表現をされることは余りない。 性能評価の第一歩はシステムの見える化であり、見える化が進むと以下のような共通の問題点が見えてくる。　

　１．資源の過剰投資
　２．アプリケーションの性能品質の悪化
　３．劣悪なサービスレベルによる運用

これらについては、事例を使って追々紹介していく。

ここで重要なのは、EXCELでグラフを作り、簡単なコメントをつけて、カラー印刷することが性能評価ではないということである。 性能評価のレベルを底上げするには、お客様に情報を公開し、厳しい目で見て頂くことが重要である。弊社は基本的な性能評価プロセス、チューニング方法などをWeb上で公開している（http://www.ibisinc.co.jp/）。

事例１～夜間バッチジョブの処理時間短縮

一つ目の事例は、最も基本的なものを紹介する。 午前２時過ぎに終了している夜間バッチジョブを短縮したいという依頼を頂いた。まず、CPU時間とIOPS（I/O per second）をグラフ化すると、CPU使用率が一時間以上100%になっていることがわかった（図１）。

図１　夜間CPU使用率の推移

注）棒グラフVM1（仮想システム１）とVM2（仮想システム２）がCPU使用率、折れ線グラフはIOPS～１秒間のIO回数．

■問題点
CPU使用率が100%のとき、I/Oはほとんど発行されずCPUループ状態である。システム管理者は，何の業務なのか正確に把握していなかった．

■原因
SMFからプログラムを特定したところ、UNIXサーバにデータ転送するためにコード変換を行っている処理であることが判明した。ソースを確認したが、製品のサブルーチンを呼んでいたため、詳細は開発者に聞かないとわからなかった。 並行してCOBOLのデバッグオプションをツールで確認したところ、CHECKオプションが付加されていることが判明した。注）CHECKオプション：実行時にテーブルのオーバフローをチェックする機能

■対処
CHECKオプションの有無で性能テストをしたところ表１のような結果になった。

表１　10万件のデータでテストした結果

効果が大きかったため、さっそく本番システムに適用することになった。

■成果
　夜間バッチのCPU時間が１時間以上削減（システム全体の30%に相当）
　夜間バッチの終了時間が40分以上短縮

■考察（本質）
　今回は処理時間がうまく短縮したが、文字コード変換処理はメモリアクセスに時間がかかる（CPUを占有する）ためメインフレームでは極力行うべきでない。 PCでできることをメインフレームでやってはいけない。
　問題のプログラムはSEから提供されたもので、お客様自身はロジックやデバッグオプションの有無を把握していなかった。性能品質の悪いプログラムがシステムに侵入し、CPUを食い潰すような事例が最近増加している。
　翌年のCPUリプレースでは現行性能の0.7倍のCPUを導入、コスト削減を実現した。