 
| Subject: | |
| From: | |
| Reply To: | |
| Date: | Mon, 20 Aug 2001 12:02:02 -0400 |
| Content-Type: | text/plain |
| Parts/Attachments: |
|
|
Hello All,
I have a question concerning Reblocking an automatic dataset and
performance. In everything I have read and heard (and it certainly makes
sense to me...) is that reblocking has no affect on performace on the new
RISC HP3000 machines - only disc space usage. This is due to the fact that
the Operating System no longer fetches data at the block level and now
fetches at the page level. A page can contain several blocks.
I have an automatic that is getting "messy". Here is the output from
Robelle's Howmessy Report:
HowMessy/XL (Version 2.5) Data Base: CLMSDB
for IMAGE/3000 databases By Robelle Consulting
Ltd.
Secon- Max
Type Load daries Blks Blk
Data Set Capacity Entries Factor (Highwater) Fact
AC-CLAIM-NUMBERS Ato 7993157 3524898 44.1% 41.0% 5192 2
Max Ave Std Expd Avg Ineff Elong-
Chain Chain Dev Blocks Blocks Ptrs ation
95 1.70 2.37 1.24 3.17 88.8% 2.55
Increasing the capacity should help cure the high percentage of secondaries
by better hashing , which it did, but at at a 30% load factor only helped
bring down the secondaries to 36%. At this capacity, this increased the
size of the dataset by a few million sectors - a high price to pay for only
5% reduction in secondaries.
So, I'm accepting the fact that I have a not so great hashing key and will
have a high percentage of secondaries. I left the capacity at its original
44% load factor. Changing the key is not an option. My strategy now is to
just make sure there is minumum I/O when reading the synonym chains by
having them already fetched into memory. As A. Rego says, "There are 'good'
secondaries and 'bad' secondaries".
Despite what I have read, I decided to experiment with the blocking factor.
This automatic has a media length of 63, so my maximum blocking factor is
40 given a buffer length of 2560. I will have around 40 bytes of wasted per
block, but I decided to give it a try anyway. To my surprise, this
automatic started looking much better - "Max Blocks" went down severely
which will help my "DBPUT" performace - "Inefficient Pointers" decreased by
half which should help my "DBGET"/"DBDELETE" performance - "Elongation" went
down also. Here is the output after reblocking:
HowMessy/XL (Version 2.5) Data Base: CLMSDB
for IMAGE/3000 databases By Robelle
Secon- Max
Type Load daries Blks Blk
Data Set Capacity Entries Factor (Highwater) Fact
AC-CLAIM-NUMBERS Ato 7993157 3524898 44.1% 41.0% 258 40
Max Ave Std Expd Avg Ineff Elong-
Chain Chain Dev Blocks Blocks Ptrs ation
95 1.70 2.37 1.00 1.97 39.6% 1.97
I then decided to Repack this automatic physically putting all synonym
chains together. Things even looked better now. "Max Blocks" decreased -
"Inefficient Pointers" decreased by half again - and "Elongation" decreased.
Here is the output after Repacking:
HowMessy/XL (Version 2.5) Data Base: CLMSDB
for IMAGE/3000 databases By Robelle
Secon- Max
Type Load daries Blks Blk
Data Set Capacity Entries Factor (Highwater) Fact
AC-CLAIM-NUMBERS Ato 7993157 3524898 44.1% 41.0% 150 40
Max Ave Std Expd Avg Ineff Elong-
Chain Chain Dev Blocks Blocks Ptrs ation
95 1.70 2.37 1.00 1.48 19.5% 1.48
THE MAIN QUESTIONS:
Comparing this final "Howmessy" report to the first, there is a vast
improvement which should yeild greater performace. Is this the case though?
Despite these improvements, is the performance not going to increase? Is
fetching at the page level so large that all of my synonym chains are
already in memory and reblocking has no affect? If so, should I not be
concerned with Ineffcient Pointers and Elongation for automatics?
Any help is greatly appreciated! Thanks for your time in reading this long
posting!
- Dave Geis
DBA Humana/ ChoiceCare
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
|
|
