「メインフレーム・コンピューター」で遊ぼうこんな時代に今さらメインフレーム・コンピューターに取り組むハメになったみんなが助けあうサイトです。RSSWordPress.orgコスパのいい社内システムの作り方メインフレームを扱っていると、軽い開発やメンテナンスにリソースを割けない、しかし、BPCも考えねば。解決策のひとつがクラウドにおくFileMakerです。Comment印刷用ページの表示データセットのI/O効率を上げる(続き)VSAMデータセットのCIサイズを最適化する順次データセットの場合、ブロックサイズの最適化はスペース量とI/Oパフォーマンスの面で効果がありました。Interval:制御インターバル)になります。VSAMのCIサイズもスペース効率とパフォーマンスに少なからず寄与します。ESDSやKSDSのシーケンシャル読みでは効果があります。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回数には影響しない傾向があります。KSDSファイルINDEX-CIサイズ別100,000レコード検索処理時間このグラフは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など)よりはデータベースの利用が多くなっているので、その場合はデータベース・システムのチューニングを必要に応じて行います。HI-LEVEL-RBA-------40960AMSのLISTCATリストによって、現在のCIサイズやINDEXレベルなどを知ることができます。CLUSTERコマンドに指定できます。INDEXのCIサイズは必ずしも指定値が採用されるわけではありません。z/OSではAMSがDATAのCIサイズやキー長などに基づき必要なサイズを算出しますが、それを下回るサイズの場合はAMSの算出値で置き換えられます。(CISZ(4096))//いずれにせよブロックサイズやCIサイズを大きくする(適切なサイズにする)だけで効果が上がるのは、順次や区分データセット、VSAMならESDSやKSDSのシーケンシャル・アクセスの場合と考えていいでしょう。