お手軽バッチ・パフォーマンス改善 – IV
データセットのI/O効率を上げる(続き)
VSAMデータセットのCIサイズを最適化する
順次データセットの場合、ブロックサイズの最適化はスペース量とI/Oパフォーマンスの面で効果がありました。VSAMの場合は、ブロックに相当するものがCI(Control Interval:制御インターバル)になります。VSAMのCIサイズもスペース効率とパフォーマンスに少なからず寄与します。特にESDSやKSDSのシーケンシャル読みでは効果があります。
CIサイズはAMSのDEFINE CLUSTERでCISZパラメーターで明示的に指定することができます。KSDSではINDEXとDATAにそれぞれ異なるCIサイズを指定できます。しかしPSやPDSのBLKSIZE=0同様に、CISZの指定を省略すればAMSがレコード長やキー長、デバイスのトラック長などから最適と思われるCIサイズを設定します。
順次データセット同様に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バイトの時のELAP時間を1とした相対数値です。
INDEX/DATA共にCIサイズをAMSのデフォルト値のままにすると、I/Oが約100,000回余計に出ていますがそれ以外の組み合わせではCIサイズの違いによるI/O回数の差はありませんでした。ELAP時間はINDEXのCIサイズを増やすほど少しずつですが増えてしまっています。
LISTCATで調べたところ、CIサイズが512の時、INDEXレベルは3、それ以外では2になっていました。INDEXレベルは目的のレコードを見つけるのに何回索引をアクセスしなければならないかを示します。そのためINDEXレベルが大きいCIサイズ512ではI/O回数が増えています。レコード長500、キー長10バイトのケースではAMSはINDEXのCIサイズを512バイトにデフォルト設定します。これはディスクスペース量にベネフィットしていますが、ランダム・アクセスにおけるパフォーマンス面では必ずしも最適なCIサイズとは言えずチューニングの余地はありそうです。
この例では1KBないしは2KBあたりを目安にできそうですが、格納されるレコード数(DATAコンポーネントのサイズ)によっても変わってくるので、INDEXレベルが少なくなるようなサイズの中で、もっとも小さいサイズに決めるようにもできます。なおMSPとVOS3ではINDEXのCIサイズは512、1024、2048、4096の4パターンしかありません。
なおランダム・アクセスでは、ランダム性が高いほどDATAのCIサイズを長くする意味はなくなってきます。KSDSでもシーケンシャル・アクセスを多く行うなら大きいCIサイズの方がパフォーマンス面では有利ですが、キーによるランダムアクセスが主であれば小さいサイズの方が有利です。ただし小さくするとそれに応じてディスク上のスペース量は増えていきますから、妥当なスペース量との兼ね合いで選択します。また2KB、4KB、8KBバイトなど区切りのよいサイズにする方法もあります。いずれにせよランダム・アクセスの場合はCIサイズだけでのパフォーマンスアップは難しいので別の観点でのチューニングも必要です。
もっとも現在ではランダム・アクセスを必要とするアプリケーションは、VSAM(KSDSのキーサーチやRRDSなど)よりはデータベースの利用が多くなっているので、その場合はデータベース・システムのチューニングを必要に応じて行います。
INDEX --------- USER.KSDS1.CLINDEX HISTORY DATASET-OWNER-----(NULL) CREATION--------2003.323 RELEASE----------------2 EXPIRATION------2005.254 PROTECTION-PSWD-----(NULL) RACF----------------(NO) ASSOCIATIONS CLUSTER--USER.KSDS1.CLUSTER ATTRIBUTES KEYLEN-----------------4 AVGLRECL---------------0 BUFSPACE---------------0 CISIZE--------------2048 RKP--------------------0 MAXLRECL------------2041 EXCPEXIT----------(NULL) CI/CA-----------------18 SHROPTNS(1,3) RECOVERY UNIQUE NOERASE NOWRITECHK NOIMBED NOREPLICAT UNORDERED NOREUSE STATISTICS REC-TOTAL--------------4 SPLITS-CI--------------1 EXCPS---------------1377 INDEX: REC-DELETED------------0 SPLITS-CA--------------0 EXTENTS----------------1 LEVELS-----------------2 <== ★ REC-INSERTED-----------0 FREESPACE-%CI----------0 SYSTEM-TIMESTAMP: ENTRIES/SECT-----------9 REC-UPDATED----------183 FREESPACE-%CA----------0 X'A0D8F6E3D70D9401' SEQ-SET-RBA--------36864 REC-RETRIEVED----------0 FREESPC------------28672 HI-LEVEL-RBA-------40960
AMSのLISTCATリストによって、現在のCIサイズやINDEXレベルなどを知ることができます。
CIサイズはAMSのDEFINE CLUSTERコマンドに指定できます。なおINDEXのCIサイズは必ずしも指定値が採用されるわけではありません。z/OSではAMSがDATAのCIサイズやキー長などに基づき必要なサイズを算出しますが、それを下回るサイズの場合はAMSの算出値で置き換えられます。
//ALLOCATE EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSIN DD * DEFINE CLUSTER - (NAME(dsname) - VOLUMES(volnam) - RECORDS(100000 10000) - RECORDSIZE(500 500) - KEYS(10 0) - CISZ(5120) - REUSE INDEXED) - INDEX (CISZ(4096)) //
いずれにせよブロックサイズやCIサイズを大きくする(適切なサイズにする)だけで効果が上がるのは、順次や区分データセット、VSAMならESDSやKSDSのシーケンシャル・アクセスの場合と考えていいでしょう。