What's LLA + VLF
LLAを利用した、又は利用しない場合の比較テスト

さて、LLAとVLFはどれほど効果があるのでしょうか？ まず、LLAを利用した場合と利用しない場合の処理時間の違いをテストプログラムを利用して比較してみます。

テスト環境

System   CPU 9021-952をRM/SMで分割した1区画   CP# 5 (3SystemでShare)   Weight 2%(No Capped)   CS 136mb   ES 136mb

テストケース１

テストは、モジュールのLOAD・DELETEを10,000回繰り返すプログラムを作成しました。 LOADするモジュールは結果がはっきり現れるように、なるべくLLAとVLFに効果があると思われるものを用意します。どのようなモジュールが効果的なのかが分からないのですが、簡単に考えて、“大量のメンバーが存在するライブラリー”は、LLAを利用するとモジュール検索時間の大幅な短縮に繋がると思われ、Fetchに時間がかかる“サイズの大きいモジュール”はVLFに効果があると考えました。そこで、以下のライブラリーを作成します。

テスト用ライブラリー   DISK Hitachi A6588-3 (3390-3型互換) 他システムから若干のアクセス有り   CHP ESCON x 6   BLKSIZE 23200   Space 65 Cyl   Extent 1   Directory Block 5000 Block   Member数 10001(小さいサイズのダミーが10,000メンバーあり、実際にLOADするメンバーは1メンバーのみ)   Module Size x'4E20A0' ( 5,120,160 Byte )

そして、このテスト用ライブラリーを“NON-LLA”・“STEPLIB+NOFREEZE”・“STEPLIB+FREEZE”・“LNKLST+STEPLIB”・“LNKLST”という条件下に設定し、処理時間の比較を実施しました。(テスト開始前には、必ずLLAとVLFの再立ち上げを実施しています) それぞれのパターンでのFetch先は右表のようになっています。

テストパターンのアクセス先 Directory Search Module Fetch NON-LLA DASD DASD STEPLIB+NOFREEZE DASD VLF(DASD Version) STEPLIB+FREEZE LLA VLF(LLA Version) LNKLST+STEPLIB(+FREEZE) LLA VLF(LLA Version) LNKLST(+FREEZE) LLA VLF(LLA Version)

テスト中はLLAのEXIT(CSVLLIX1)を組み込み、LOADしたモジュールがDASD(PGMF)から、もしくはVLF(LLAF)からFetchされたかを調べる事が出来るようにしました。

テスト結果 START END ELAPSE EXCP CONN SERV PAGE SWAP PGMF LLAF NON-LLA 18:23:34 18:37:04 13:30 20249 678K 119K 0 0 N/A N/A 18:39:19 18:52:46 13:27 20249 678K 117K 0 0 N/A N/A STEPLIB+NOFREEZE 18:04:49 18:20:44 15:55 18581 708K 317K 0 0 8001 1999 18:55:22 19:10:54 15:32 18582 694K 299K 0 0 8002 1998 STEPLIB+FREEZE 17:47:12 17:51:00 3:48 8585 58346 324K 0 0 8005 1995 19:14:33 19:18:02 3:29 8592 58384 301K 0 0 8012 1988 LNKLST+STEPLIB 17:00:19 17:04:58 4:39 8590 45895 327K 0 0 8010 1990 19:21:22 19:25:00 3:38 8585 58326 309K 0 0 8005 1995 LNKLST 17:16:56 17:21:07 4:11 8583 58365 327K 0 0 8008 1992 19:26:52 19:30:34 3:42 8585 58361 321K 0 0 8010 1990 凡例 START JOB開始時間 END JOB終了時間 ELAPSE 処理時間 EXCP EXCP回数 CONN CONNECT TIME SERV PAGE PAGE-IN回数 SWAP SWAP回数 PGMF DASDからFetchした回数 LLAF LLAからFetchした回数 テストの結果で処理時間が短いパターンは、LLAからディレクトリー検索しているもので、DASDからディレクトリー検索しているものに比べ１／４程度の処理時間で終了しています。この結果からLLAは素晴らしい効果がある事が分かると思います。 そして、予想と大きく異なっていた事はVLFによるModule Fetchです。PGMFとLLAFの項目を見ていただくと判るように、VLFからFetchする様に指定していたケースであっても３／４はDASDからFetchを行っていました。このFetchは最初の数十〜数百回はDASDからFetchし、その後VLFからFetch、そして後半は結局DASDからFetchするというパターンとなっていました。LLAFのFetch回数は、ほぼ2000回であり、これは、モジュールステージング分析機能のサイクルだと思われます。おそらくLLAは“VLFからFetchするよりも、DASDからFetchする方が良い”と判断した結果だと思われます。これは、プログラム内で測定した1回当りのFetch時間(LOAD/DELETEのLoopの前後にTIMEマクロでタイムスタンプを取得していました)も、DASDの方が高速である事を表していましたし、“NON-LLA”と“STEPLIB+NOFREEZE”の処理時間もVLFを使用しない方が高速である事を表しています。 このテストではVLFの効果は全く無く、LLAはDirectory Searchが非常に高速になり、Module Fetchの処理時間の短縮にはつながらないという結果となってしまいました。

テストケース２

さて、VLFは本当に効果が無いのでしょうか？ 私がテストした環境はCS、ES共、136MBという、少ないストレージの割り当てしかありません。COFVLFxxのMAXVIRTは4096となっており、VLFはCSVLLAの為に16MB(4096×4Kブロック)の記憶域を用意しているはずです。この値はシステムに割り当てたストレージの12%に相当し、恐らく大半はページアウトされていると思われます。LOADを行ったモジュールサイズは約5MBでしたから、VLFのCSVLLAクラスの1/3程度を占める事となり、ページングの為にDASD FetchよりもVLF Fetchの方が遅くなったのではないかと考えられます。そこで、LOADするモジュールのサイズを小さくして、再テストを実施しました。 LOADするModule Sizeはx'4E20A0'バイトからx'0a'バイトという、小さなモジュールに変更しました。

テスト結果 START END ELAPSE EXCP CONN SERV PAGE SWAP PGMF LLAF NON-LLA 15:10:30 15:23:48 13:18 20249 685K 43961 0 0 N/A N/A 15:51:36 16:04:51 13:15 20249 685K 44111 0 0 N/A N/A STEPLIB+NOFREEZE 15:31:42 15:44:24 12:42 10603 651K 54838 0 0 23 9977 16:08:18 16:20:51 12:33 10591 651K 54766 0 0 11 9989 STEPLIB+FREEZE 15:27:57 15:28:21 0:24 595 663 37860 0 0 15 9985 16:31:28 16:31:58 0:30 601 784 37117 0 0 21 9979 LNKLST+STEPLIB 15:27:57 15:28:21 0:24 595 663 36860 0 0 0 10000 16:39:07 16:39:46 0:39 608 776 36749 0 0 28 9972 LNKLST 14:57:56 14:58:35 0:39 592 739 36720 0 0 15 9983 16:45:58 16:46:34 0:36 609 759 36295 0 0 34 9966 テストケース１とは異なり、“NON-LLA”よりも“STEPLIB+NOFREEZE”の方が、若干ですが処理時間が短くなっています。PGMFは20回程度となり、ほとんどがLLAFとなっています。LLAはVLFを利用した方が高速であると判断し、2000回Fetchを繰り返した後であっても、再びDASD Fetchを行う事はありませんでした。

Whats LLA + VLF Tips home

- Kimu : 1998.06.30 - 1998.11.07 -