【2010/07/25 original author KAMII】
データセットのI/O効率を上げる
アプリケーションのバッチ処理では、ファイル（データセットやデータベース）に一切アクセスしないものは少ないです。たいていのプログラムはファイルからデータを読み取り、集計や帳票の作成など何らかの業務的な加工処理を行います。また、データを変換して別のファイルに新たなデータとして書き出したり、既存のデータを更新したりします。そのような処理では必ずI/Oを伴いますから、I/O効率を上げることはパフォーマンスの改善に大きく寄与します。ここではI/O効率を見直す中で比較的アプローチしやすいもので考えてみます。
z/OSのDFSMSのマニュアルに次のような解説があります。
「入出力パフォーマンスは、データを仮想記憶域へと、または仮想記憶域から転送するために必要なプロセッサー時間とチャネル始動／停止時間の両方を削減することによって改善されます。パフォーマンスに影響を及ぼすいくつかの要因を以下に示します。」
- アドレス・スペース・タイプ(実または仮想)
- ブロック・サイズ
- QSAM でのBUFNO
- BSAM でのオーバーラップ要求の数（NCP=チャネル・プログラムの数）およびDCBがMULTACCをコーディングされたDCBEをポイントしているかどうか
- プロセッサーおよびチャネルでの他のアクティビティー
- 装置クラス（例えば、DASD、テープ） およびタイプ（例えば、IBM3390、3490）
- データ・セット・タイプ（例えば、PDSE、UNIX、拡張フォーマット）
- ストライプの数（拡張フォーマットの場合）
ブロックが大規模になるほど効率的になります。LBI（大規模ブロック・インターフェース）を使用することによって大幅なパフォーマンス改善を得ることができます。LBIは32760バイトより長いテープ・ブロックを許可します。
1番目のアドレス・スペース・タイプについては考える必要はありません。ずいぶんと昔は高いパフォーマンスでジョブを動かすために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つ、7番目と8番目はz/OSならではのもので、拡張フォーマットやストライピングをサポートした新しいタイプの順次データセットや拡張区分データセットではアクセス効率もよくなっていますが、業務用のデータセットやライブラリーをそれらに移行することになるので計画的に行う必要があります。規模が大きいと簡単には行かないでしょう。
【2010/07/25 original author KAMII】