SysAdmin's Group システム管理者の会
日本最大規模の
システム管理者のネットワーク

運用ノウハウを学ぶ

システム管理に関わるベーシック情報やトレンドをご案内します!

富士通メインフレームの本質を見る~バッチ処理の性能評価と改善事例 第5回 バッチ処理の性能改善術
2007年10月24日 20:04

「最新のxxを導入したところ、バッチ処理時間が1/10に短縮しました!」
 よくある広告ですが、これが自社製品を使って頂いているお客様へのメッセージであると、悲しい気分になってしまいます。このお客さんは、今まで適切な性能改善をしてもらえず、どれだけ不自由な想いをしてきたのでしょう。
 前回まで6件の事例を紹介してきましたが、これらを整理するためメインフレームの特長を生かした性能改善の手法を説明します。これは、有賀式性能評価手法のベースとなっている考え方です。(http://www.ibisinc.co.jp/colum0601.htm

手法1~バッチ処理の処理時間モデル

 メインフレームにおけるバッチ処理の処理時間モデルを図7に示します。

image37.PNG

図7 バッチ処理の処理時間モデル

■解説

  • 基本的に、①I/O時間と②CPU時間から構成される。メモリアクセスの時間は②CPU時間に入る。
  • ①I/Oと②CPUのバランスは、第4回-図6で紹介したCPU/IO頻度という考え方の基本となっている。
  • 10年前のSEは、I/O回数やダイナミックステップ数を算出し、処理能力見積りを行っていた。
  •   
    I/O時間=I/O回数×I/O性能値
      
    CPU時間=ダイナミックステップ数×CPU性能値
  • バッチ処理における③CPU待ち時間は、待ち行列理論に基づかず、第2回-図3で紹介した通りジョブの多重度で増減する。
  • ④その他の待ち時間には、OS上での待ち、データベースの排他待ち、I/O待ち、メモリ制御による待ち時間等がある。性能データから待ち時間の内訳を把握することは、状況に応じたテクニックが必要である。
  • ①'②'の無駄には、ユーザアプリ上の無駄とOS上の無駄が考えられる。無駄の多いプログラムを性能品質の悪いプログラムと呼んでいる(第4回)。
 どんなに処理時間が遅くても、①~④のどこかで時間を費やしています。冒頭の処理時間が1/10に短縮した件は、大きなボトルネックがあったものと考えられます。
 メインフレームには優れたトレース機能が用意されているので、処理時間の内訳はおよそ把握することができます。これはメインフレームの大きな強みです。

例題2~以下の無駄が起きているとき考えられる原因の例は?

  1. I/O時間(I/O回数)の無駄 かつ CPU時間の無駄
  2. I/O時間(I/O回数)だけの無駄
  3. CPU時間だけの無駄

手法2~バッチ処理の性能改善

 夜間バッチ処理時間を削減するためのアプローチ例を図8に示します。

ariga-1024.png

図8 夜間バッチ処理時間削減へのアプローチ

■解説

  • システム資源を有効に活用する
  • いわゆるシステムチューニングである。SDMの設定により、優先させたい処理のプライオリティを上げる。I/O処理はより高速な記憶媒体で行いI/O時間を短縮する。
  • 長時間ジョブのチューニング
  • 性能品質の悪いプログラムがあれば原因を調査する。COBOLのデバッグオプションもロードモジュールから確認する(第1回-図1)。途中実更新とは、データベースの入出力バッファが不足し、トランザクションの途中でデータベースへの実更新行う動作である。(⇔一括実更新)
  • 処理(ステップ)の無駄をなくす
  • 不要な処理はないか。意味のないバックアップを行っていないか。
  • ジョブネットの見直し
  • 資源(特にCPU)が過負荷状態でジョブの遅延が起きているときは、実行される時間帯を変えられるジョブ群がないか調査する。

 性能を改善するということは、図7で紹介した処理時間モデルを作り、無駄を無くす、待ち時間を無くす、それでもだめならI/O性能を上げる、 CPU性能を上げるということになります。経験と勘も重要ですが、第2回で紹介したように今までの常識が通用しなくなっていることに気付く必要があります。

例題3~資源の負荷が低く処理が遅いときの対応は?(例えば、第3回-図4

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

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

記事一覧へ
筆者紹介

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



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

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回にわたり掲載。

  • 新着Q&A
  • 最新の回答
回答数:22019年11月12日

システム管理者認定講座<全コース共通>試験のみ受験希望の方はこちら

動画で見るセミナー
動画で見るセミナー

毎年恒例となった「システム管理者の会」の年に一度の大イベントとなる「システム管理者感謝の日イベント」の模様をお届けします。 今年のテーマは、「集まれ若いチカラ!システム管理者のための夏期講習!!」です。

個人情報保護方針
運営者につい て
利用規約
サイトマップ