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

第4回　性能品質の悪いプログラムを捜す

概要

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

性能品質が悪いとは、ある機能を実現するのに標準以上の資源（CPU、I/O）を使っていることと定義する。標準は任意に設定でき、例えば次の３つのケースが考えられる。

①CPU頻度が異常に高い　　　 例）大きなテーブルサーチ、文字コード変換
②I/O頻度が高い、I/Oが多い　　例）システムファイルにI/Oが多い、ブロック長が短い
③無駄な処理をしている。 　　 例）無駄な処理の実行、不適切なSQLの発行 システム全体のリソースに問題がなくても、性能品質の悪いプログラムを把握し、状況に応じて改善していくことは重要である。

目次
事例６～夜間バッチ処理を速くしたい（後半）

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

前回の表４のように、このシステムにはCPUの過負荷と特定ボリューム（実際はシステムボリューム）の高負荷に問題があった。そこで、CPU使用量の多いジョブ、システムボリュームへのI/Oの多いジョブを調査したところ、性能品質の悪いプログラムが見つかった。
 
■問題点
a) バッチジョブIExxのCPU頻度が高く、CPU使用量も多い。（表５）
  （更に、CPUレベルアップの前後でCPU時間が変わっていないことが判明）
b) バッチジョブIAxxがシステムボリュームに20%の負荷を与えている。
c) バッチジョブIGxxのCPU頻度が高く、CPU使用量も多い。（表５）
 
■原因
a) トレースとプログラムソースを調査したところ、時間取得のACCEPT命令をループさせ1秒間待つロジックが
使われていることが判明した（数年前の修正モレ）。ACCEPT命令でCPUが使われ、1秒ループさせるためにCPUをレベルアップしてもCPU時間が減らない結果となっていた。⇒ ①のケース
 b) システムボリュームへのアクセス状況をトレースで調査したところ、バッチジョブIAxxがI/Oの半分を発行していることが判明した。更に詳細を調査したところ、ARCS（バックアップユーティリティ）のプログラムを呼ぶためにLINKLIBをアクセスしていることがわかった。（ARCSのボリューム圧縮機能）⇒ ②のケース
 c) 開発者がプログラムを調査したところ、プログラム内でテーブルサーチが多いことがわかった。⇒ ①のケース
 
■対処
a) ACCEPT命令を止め、WAITするサブルーチン（ユーザ保有）を使うようにプログラムを修正した。
b) 圧縮対象ボリュームの余裕度を調査し、圧縮の実行回数を半減した。更に、プログラムのローディング回数を削減するため、１ステップで複数ボリュームを処理するように修正した。
c) テーブルの一部をVSAM化に変更した。
 
■成果
改善結果を表５に示す。cは改善後もCPU/IO頻度が高く、この時点で改善は不十分であると予想する。
表５　バッチジョブの性能改善状況
*1 CPU占有率＝CPU時間/処理時間　*2 IOPS(I/O per second)=I/O回数/処理時間  *3 参考（本質）を参照
■考察（本質）
      • 問題プログラム（ジョブ）の特定は、PDLやSMFといった性能データで行える。原因調査には、メインフレームの強い武器であるトレースを活用するのが迅速かつ正確である。
      • cの改善が不十分なのは、開発者と意思の疎通がとれていないことも原因の一つと考えられる。
      • システム管理者に気づかれず、多量のリソースを浪費しているようなプログラムはどのシステムにはいくつか動いているものである。従来は、ジョブのCPU使用量が大きくてもその妥当性を評価できなかったが、例えばCPU/IO頻度という考え方を取り入れると無駄の状況を見える化することができる。
      • CPU/IO頻度とは、当社が独自に開発した指標で、CPUとI/Oのバランスを示している。これは、表５のように個々のジョブに対しても、また図６のようにシステム全体に対しても適用することができる。100社以上の性能データをもとに、標準値が20～40になるように算出している。
 
図６　CPU/IO頻度分析

連載一覧

コメント

筆者紹介

有賀　光浩（ありが　みつひろ）

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

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

バックナンバー