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

目次

事例４～データベースの創成処理（リロード）が遅い

図４　システムの稼動状況（リロード処理の実行時）

表３　改善結果の推移

事例５～夜間バッチ処理を速くしたい（前半）

表４　システムから見た問題点

事例４～データベースの創成処理（リロード）が遅い

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

図４　システムの稼動状況（リロード処理の実行時）

表３　改善結果の推移

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

事例５～夜間バッチ処理を速くしたい（前半）

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

表４　システムから見た問題点

■課題設定
業務要件とシステムの状況をすり合わせした結果、処理時間の２時間短縮（10時間→８時間）を目標と設定した。これを実現するための課題は以下の３点である。 CPU使用率100%で運用できる環境を構築する。 無駄に使っている資源（CPU、I/O）を削減する。 I/Oネックを起こさないようよう負荷分散を図る。

■考察（本質）
現状を見える化し、システムから見た問題を正確に把握することが最初のステップ。 CPU使用率100%で運用できるのがメインフレームの強み。 例題１～以下のバッチ処理は遅いか否か、またその理由は？

第１回、事例１で紹介したコード変換のバッチ処理
第２回、事例２で紹介したSORT処理