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

運用ノウハウを学ぶ

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

富士通メインフレームの本質を見る~バッチ処理の性能評価と改善事例 第3回 バッチ処理が遅い
2007年07月18日 19:32

今回は、「バッチ処理が遅い」ことについて考える。遅いと認識するには比較する対象が必要であり、これがないと遅いことに気づかず、問題意識も生まれない(よくあるケース)。
比較する対象には、①業務目標、②システム自身、③システム目標などが考えられ、それぞれ、①'朝6時までに夜間バッチが終わらない、②'通常10分の処理が1時間以上かかる、③'見積りの倍以上の時間がかかる、といった例があげられる。
SEに③'を指摘された経験はほとんどないが、この感性がとても重要である。
遅い原因をシステムから見ると、a)必要な処理をしていた、b)余分な処理をしていた、c)待たされていた、の3つである。 事例を使って、バッチ処理が遅い本質を見ていきたい。

事例4~データベースの創成処理(リロード)が遅い

レコード件数60万件、レコード長500バイト(300MB)のデータベースを創成する(リロード)のに2時間かかっているが妥当なのかとの相談を受けた。なお、この処理が実行されているときのシステム資源には十分余裕がある(図4)。
ariga0718.png
図4 システムの稼動状況(リロード処理の実行時)

■問題点
リロードの処理能力(=データ量/処理時間)を算出すると300MB/7200秒=0.04MB/Sとなる。通常のシーケンシャルREAD/WRITEは数MB/Sの処理能力がでるので、これは異常なほどの遅さである。リロードがほぼ単体で実行されているときのCPU使用率は5%未満であることも図4(点線内)からわかる。

■原因
このデータベースは、キー順に並んだデータが完全に分散されるように作られていた(ネットワークデータベースNDBのシステムランダマイズルーチンを利用)。そのため、データベース創成時のWRITEが全てキャッシュヒットしないため、I/Oレスポンスが約11msかかっていた。
 さらに、1レコードごとに実I/Oが発生し(ブロック化されていないのと同じ)ており、I/O処理だけで、60万件×11ms=66,000秒=1時間50分かかってしまう計算となる。

■対処
a) データベースをシーケンシャルファイルにアンロードした直後の(物理順の)並びを覚えておき、業務処理終了後、この並びに戻しリロードする。
この操作により、物理順に近い並びで処理ができるため、キャッシュヒット率の向上とブロッキング化(実I/Oの削減)の両方が改善されることになる。
b) アンロード時の情報を残しておけるだけのキャッシュを増設する。
なお、並びの保持や並び替えの処理が追加されるが、300MBのデータを普通に処理するには100秒前後しかかからない。

■成果
対処bとaを実施した結果を表3に示す。
表3 改善結果の推移
image33.PNG
■考察(本質)
IN/OUTのデータ量などから、およその処理能力を把握し、遅いか否かを客観的に判断することができる。
3のDで83%の性能改善が実現されたとしても、処理能力はまだ300MB×1.36/1,608=0.25MB/Sである。これはデータベースがランダム性を重視しているため、1ページ(ブロック)に2~3件(1.5KB)のレコードしか格納していないためである。ブロッキング効率が上げれば10倍以上の性能向上が期待できる。

事例5~夜間バッチ処理を速くしたい(前半)

問題の特定ができていないが、何しろ夜間バッチ処理を速くしたいケースを考える。メインフレームでは一晩に1,000本以上(万の単位もある)のジョブが実行されており、これらを一本ずつ見ていくのは現実的でない。まず、何時間短縮したいのか、システムから見てこれは現実的なのかを把握する必要がある。事例を使ってこの改善プロセスを紹介する。図5にはCPUの使用状況を示す。
ariga-0718-2.png
図5 夜間バッチ処理のCPU使用状況


■問題点(現状把握)
システムにボトルネックがあれば処理時間の短縮は実現しない。システムから見た問題点を表4に示す。

表4 システムから見た問題点
image34.PNG

■課題設定
業務要件とシステムの状況をすり合わせした結果、処理時間の2時間短縮(10時間→8時間)を目標と設定した。これを実現するための課題は以下の3点である。

  • CPU使用率100%で運用できる環境を構築する。
  • 無駄に使っている資源(CPU、I/O)を削減する。
  • I/Oネックを起こさないようよう負荷分散を図る。

■考察(本質)

  • 現状を見える化し、システムから見た問題を正確に把握することが最初のステップ。
  • CPU使用率100%で運用できるのがメインフレームの強み。

例題1~以下のバッチ処理は遅いか否か、またその理由は?
 

  1. 第1回、事例1で紹介したコード変換のバッチ処理
  2. 第2回、事例2で紹介したSORT処理
運用研究レポート
富士通メインフレームの本質を見る~バッチ処理の性能評価と改善事例

多くの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日

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

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

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

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