富士通メインフレームの本質を見る~バッチ処理の性能評価と改善事例

第2回 5年前の常識は通用しない

概要

多くのSEはシステムの性能評価が不得手です。そのため、お客様がシステム性能の主導権を握れると、コスト削減・品質向上につながります。バッチ処理の性能改善事例を使い、性能問題の裏にある本質を皆さんと一緒に考えていきます。事例は富士通メインフレーム上のものですが、改善へのプロセスや本質はどのメーカでも共通点があると思います。

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

目次
事例2~SORTがCPUを多量に使うのは本当に仕様か?
事例3~メインフレームは本当に多重処理に強いのか?

事例2~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)’と設定した。

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

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

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

 

事例3~メインフレームは本当に多重処理に強いのか?

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

表2 CPU統合前後の比較

カッコ内はレベルアップ前との比較     

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

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

 

図3 バッチジョブの処理時間のシミュレーション結果

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

■考察(本質)

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

連載一覧

コメント

筆者紹介

有賀 光浩(ありが みつひろ)

株式会社アイビスインターナショナル 代表取締役

1963年生まれ。1985年富士通株式会社入社。1992年~2003年まで社内共通技術部門で国内外のメインフレームの性能コンサルティングを実施、担当したシステム数は1,000を超える。2000年からは大規模SIプロジェクトへの品質コンサルティング部門も立ち上げた。

2004年に株式会社アイビスインターナショナルを設立。富士通メインフレームの性能コンサルティングとIT統制コンサルティングを行っている。

技術情報はhttp://www.ibisinc.co.jp/で公開中。富士通やSI’erからのアクセスが多い。

当サイトには、同名シリーズ「富士通メインフレームの本質を見る~IT全般統制の考え方」を3回、「富士通メインフレームの本質を見る~バッチ処理の性能評価と改善事例から」を6回、「富士通メインフレームの本質を見る~CPUリプレースの考え方」を3回、「富士通メインフレームの本質を見る~性能改善の現場」を7回、「富士通メインフレームの本質を見る~2009年度の最新トッピックス」を3回、「富士通メインフレームの本質を見る~2008年度の最新トピックス」を2回にわたり掲載。

バックナンバー