お手軽バッチ・パフォーマンス改善④更新版

【2010/07/26 original author KAMII】

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

VSAMデータセットのCIサイズを最適化する

順次データセットの場合、ブロックサイズの最適化はスペース量とI/Oパフォーマンスの面で効果がありました。VSAMの場合、データセットを利用する側から見た時のブロックに相当するものがCI（Control Interval：制御インターバル）です(*1)。VSAMのCIサイズもスペース効率とパフォーマンスに少なからず寄与します。特に、ESDSやKSDSのシーケンシャル読みでは効果があります。
CIサイズは、AMSユーティリティーのDEFINE CLUSTERのCISZパラメーターで明示的に指定することができます。KSDSではINDEXとDATAにそれぞれ異なるCIサイズを指定できます。しかし、PSやPDSのBLKSIZE=0同様に、CISZの指定を省略すればAMSがレコード長やキー長、デバイスのトラック長などから最適と思われるCIサイズを設定します。

*1 VSAMではCIとDISKに書き込まれる物理レコードは必ずしも1対1に対応しない。物理レコードのサイズはトラック使用効率が最も良くなるような大きさにVSAM側で調整される。なお、1つのCIが複数の物理レコードに分かれても、複数の物理レコードにまとめてアクセスするなど効率面も考慮されたI/O処理が行われる。

順次データセット同様に、VSAMでもCI長が大きくなるにつれ同じレコード数なら必要とするディスク・スペース量が減っていくことを示しています。また、CIサイズが大きくなればEXCP発行回数も減っていくので、大きなCIサイズはパフォーマンス面でも有効なことがわかります。レコード長が500バイトの時、AMSのデフォルトCIサイズは約18KBです。より大きなCIサイズではさらにEXCP回数を減らせますが、ELAP時間はそれに比例して減ってはいません。一千万を超えるほどのレコード数があれば、わずかな差も積み上がりますが、デフォルトCIサイズのままで問題はないでしょう。
大きなCIサイズを持つこと自体がパフォーマンス面で有効なのは、レコードを順次に処理するシーケンシャル・アクセスに関してです。順次アクセスの場合は、読み込んだブロック内のレコードを次々に処理できますが、ランダム・アクセスの場合は読み込んだブロック内の他のレコードが次のアクセスで使われる確率が減るので、ブロックが大きくても小さくても目的のレコードを読み込むためのI/O回数には影響しない傾向があります。

このグラフは500バイトの固定長レコード（うち先頭10バイトが検索キー）が100,000レコード格納された3390型ディスク上のVSAM/KSDSデータセットを、同じCIサイズのDATAと異なるCIサイズのINDEXの組み合わせによるアクセス・パフォーマンスを示したものです。いずれも同じプログラムを使い、検索対象のキー値は同じ順序で出現するようにしてそれぞれ100,000回のキー検索をしたものです。
左側はDATAのCIサイズをAMSデフォルトの18432バイト、右側は4096バイトにしたものです。右側のテストでは、最も小さいCIサイズが1536ですがこれはDATAのCIサイズ4096ではINDEXに512バイトのCIサイズを設定できなかったからです。ELAP時間とCPU時間は、AMSがデフォルトで設定するINDEXのCIサイズ512、DATAのCIサイズ18432バイトの時のELAPSとCPUをそれぞれ1とした相対数値です。

INDEXとDATA共にCIサイズをAMSのデフォルト値のままにすると、I/Oが約100,000回余計に出ていますがそれ以外の組み合わせではCIサイズの違いによるI/O回数の差はありませんでした。DATAのCIサイズがデフォルト値の場合、ELAP時間はINDEXのCIサイズを増やすと最初（1KBや4KB）は効果が出ますが、さらにCIサイズを大きくしていくと少しずつですが逆に増えてしまっています。
LISTCATで調べたところ、CIサイズが512の時はINDEXレベルが3、それ以外では2になっていました。INDEXレベルは目的のレコードを見つけるのに何回索引をアクセスしなければならないかを示します。そのため、INDEXレベルが大きいCIサイズ512ではI/O回数が増えています。レコード長500、キー長10バイトのケースではAMSはINDEXのCIサイズを512バイトにデフォルト設定します。これはディスクスペース量には有益ですが、ランダム・アクセスにおけるパフォーマンス面では必ずしも最適なCIサイズとは言えずチューニングの余地はありそうです。
この例では、INDEXのCIサイズ1KBないしは2KBあたりを目安にできそうですが、格納されるレコード数（DATAコンポーネントのサイズ）によっても変わってくるので、INDEXレベルが少なくなるようなサイズの中で最も小さいINDEX CIサイズに決めるようにもできます。なお、MSPとVOS3ではINDEXのCIサイズは512、1024、2048、4096の4パターンしかありません。

なお、ランダム・アクセスではランダム性が高いほどDATAのCIサイズを長くする意味はなくなってきます。KSDSでもシーケンシャル・アクセスを多く行うなら大きいCIサイズの方がパフォーマンス面では有利ですが、キーによるランダム・アクセスが主であれば小さいサイズの方が有利です。ただし、小さくするとそれに応じてディスク上のスペース量は増えていきますから、妥当なスペース量との兼ね合いで選択します。2KB、4KB、8KBバイトなど区切りのよいサイズにしてみてもいいでしょう。いずれにせよランダム・アクセスの場合は、CIサイズ調整だけでのパフォーマンス・アップは難しいので別の観点でのチューニングも必要です。
もっとも現在ではランダム・アクセスを必要とするアプリケーションは、VSAM（KSDSのキーサーチやRRDSなど）よりはデータベースの利用がほとんどでしょうから、その場合はデータベース・システムのチューニングを必要に応じて行います。

AMSのLISTCATリストによって、現在のCIサイズやINDEXレベルなどを知ることができます。

CIサイズはAMSのDEFINE CLUSTERコマンドに指定できます。なお、INDEXのCIサイズは必ずしも指定値が採用されるわけではありません。z/OSではAMSがDATAのCIサイズやキー長などに基づき必要なサイズを算出しますが、それを下回るサイズの場合はAMSの算出値で置き換えられます。

いずれにせよブロックサイズやCIサイズを大きく（適切なサイズに）するだけで効果が上がるのは、順次や区分データセット、VSAMならESDSやKSDSデータセットのシーケンシャル・アクセスの場合と考えていいでしょう。

【2010/07/26 original author KAMII】