お手軽バッチ・パフォーマンス改善 – II

By 神居 - Posted: 2010/07/25 Last updated: 2010/07/25 - Leave a Comment

データセットのI/O効率を上げる

アプリケーションのバッチ処理では、ファイル(データセット、データベース)に一切アクセスしないものは少ないです。たいていのプログラムはファイルからデータを読み取り、集計や帳票の作成など何らかの業務的な加工処理を行います。またデータを変換して別のファイルに新たなデータとして書き出したり、既存のデータを更新したりします。そのような処理では必ずI/Oを伴いますから、I/O効率を上げることはパフォーマンスの改善に大きく寄与します。ここではI/O効率を見直す中で比較的アプローチしやすいもので考えてみます。

z/OSのDFSMSのマニュアルに、次のような解説があります。
「入出力パフォーマンスは、データを仮想記憶域へと、または仮想記憶域から転送するために必要なプロセッサー時間とチャネル始動/停止時間の両方を削減することによって改善されます。パフォーマンスに影響を及ぼすいくつかの要因を以下に示します。」

最初のアドレス・スペース・タイプについては考える必要はありません。ずいぶんと昔は高いパフォーマンスでジョブを動かすためにJCLのEXEC文にADDRSPC=REALという指定をしたものもあったようですが(V=Rジョブ)、もはや使われてはいないでしょう。V=Rはジョブのメモリーを実記憶に固定します。筆者は自分で使ったことがないので想像ですが、ページング・オーバーヘッドをなくしたり、特別な理由でページングされると困るようなプログラム、I/Oを直接発行するようなプログラムで処理効率を上げるため仮想アドレスと実アドレスが同じであることを前提にしたいプログラムなどのために使われたのだと考えます。
2番目と3番目のブロックサイズとBUFNOは簡単な知識と手間で、意外と効果を得られたりします。4番目のBSAMは今ではアプリケーションプログラムではほとんど使われないため考えなくていいでしょう。COBOLなどのコンパイラーも基本的にはQSAMを使用していると思ってます。
5番目のアクティビティーは、CPUとチャネルが他のジョブで使われていればその間は待たされる、ということです。6番目はデバイスの種類によってI/Oパフォーマンスは変わることを示しています。テープよりはディスク、同じディスクでもモデルによって変わります。またOSからは同じモデルに見えても、ハードウェアとしてのグレードによってもI/Oパフォーマンスは変わります。
残りの2つはz/OSならではのもので、拡張フォーマットやストライピングをサポートした新しいタイプの順次データセットや拡張区分データセットではアクセス効率もよくなっていますが、業務用のデータセットやライブラリーをそれらに移行することになるので、計画的に行う必要があります。規模が大きいと簡単には行かないでしょう。

Posted in オペレーション・運用 • • Top Of Page