【2010/07/25 original author KAMII】
パフォーマンス・チューニングというと、とかくRMFレポートと格闘してWLMのワークロードやサービスクラスの設定を試行錯誤するというイメージがあります。より細かい現状分析にはRMF（MSPではPDA）レポートなどを見ることは避けられませんが、ここではそんな高度（面倒）なことではなく、もっと身近なもので比較的お手軽にできるパフォーマンス・アップを考えてみます。
いろいろなアプローチがありますが、大きく分けるとCPU使用量を減らすかI/O効率を上げるかになります。その他にも「待ち」を減らす、というのもあります。ジョブの多重度が上がるほど「待ち」はELAP時間（実行時間）に大きく影響します。CPUを10秒使う、I/Oを100000回行う、といった同じ処理を実行しても、そのジョブしか動かない場合ではELAP時間は30秒なのに、他に別の10ジョブが並行して動いているような場合では2分掛かる、という具合です。このような待ち時間の大小によるパフォーマンスのぶれを調整し、適切なリソース配分やプライオリティ調整をすることもチューニングの大切な作業です。しかし、それはこのトピックの目的とずれてしまうので機会を改めることとしここでは採り上げません。このトピックでは個々のジョブ・ステップ単独での効率アップについて考えてみます。
アプリケーションプログラム自身が使うCPU使用量を減らす
プログラム論理を見直してCPU使用量を削減するのは、元がよほどひどいプログラムでない限りあまり大きな期待はできません。そういう箇所を見つける苦労の割りには効果が薄いです。現実的にはコンパイラーのOPTIMIZE関連オプションによって最適化されたコードを生成する、という感じでしょうか。最適化は実行コードとストレージ量の2つの観点によって行われます。
また、コンパイラーで注意すべきことの1つとしてデバッグ・オプションの付けっぱなしがあります。何らかの理由で後から1本だけ直してテストしたものが、誤ってデバッグ・オプションが付いたまま運用されてしまったようなケースです。本来なら不要な命令を常に実行し続けることになります。何かあったときに調べられないと困るから、デバッグ・オプションははずせないという考え方もありますが、基本的には業務システムの運用では不要でしょう。
I/Oを減らせばELAPSもCPUも減る
プログラムの特性としてCPUバウンダリーなのかI/Oバウンダリーなのかというのがあります。メインフレーム、特にバッチ処理ではCPUバウンダリーの代表例がデータの圧縮、I/Oバウンダリーの代表例がデータのコピーです。編集や加工を伴わない単純なものほどI/Oバウンダリーに傾きます。CPUによる命令の実行処理に比べればI/Oは時間が掛かる処理ですから、I/Oが減ればプログラム自体の実行時間（Elapsed Time）は減ります。
また、I/Oに掛かる処理はすべてがデバイスの動作待ち時間ではありません。OSにとってI/Oの制御というのはとっても複雑な処理です。アプリケーションプログラムでは単にREAD、WRITEと書くだけですが、実際にそのI/O要求がチャネルに渡るまでにOSはさまざまな制御ロジックを実行します。I/Oが完了した後も、要求したI/Oが正しく実行できたかを調べアプリケーションプログラムにファイルのレコードデータとして渡すなどの制御ロジックを実行します。これらI/O制御の処理にもCPUは使われますから、I/OバウンダリーなプログラムほどI/O回数を減らすことはそれに伴って使われるCPU量を減らすことになります。
なお、ここで言う「I/O回数を減らす」は、I/Oをやめるということではありません。業務プログラムで10000件のレコードを処理しなければならないとして、それを半分の5000件だけ処理してやめるという訳には行きません。同じ10000件のレコードの処理に伴うシステム側の入出力処理の効率を少しでも上げて、結果としてCPU使用量を減らす、という観点で考えてみます。
【2010/07/25 original author KAMII】