In message <[log in to unmask]>, Gilles
Schipper <[log in to unmask]> writes
>I'd add as well ..
>
>Your problem is not really that large. After all you've only got 20000
>entries. If you're DBPUTing or DBDELETEing infrequently, there's no
>issue. Otherwise, the max.blocks could hurt performance.
Not true, surely? Every DBGET is nearly one-and-a-half DBGETs, compared
with a well-distributed master. That will slow things down, not just for
this master, but for every detail access using it for the chain head.
And it's certainly true that every pointer is crossing a block boundary,
hence the Ineff of 100%. So, yes, up the block factor. How big is a
record?
Your analysis doesn't show what the Search Filed and Type is; it's not
binary, is it?
But under 'Master Dataset Solutions', the HowMessy manual says:
"If secondaries are over 30% and inefficient pointers are over 50%, the
dataset is either too full or not hashing properly. Increase capacity to
a higher odd number, or change the data type and format of the search
field.
Increasing block factor should reduce inefficient pointers.!
Both these prescriptions apply to the figures you give.
Roy
>At 01:20 PM 2008-02-08, Jim Phillips wrote:
>>So, I ran Howmessy on the main data base here and the very first data
>>set looks very suspicious. The report for this manual master shows
>>78% full (19381 entries, 24859 capacity), 30.3% secondaries, maximum
>>blocks=190, blocking factor=1, maximum chain=7, average chain=1.43,
>>standard deviation=.70, expanded blocks=1.43, average blocks=2.30,
>>elongation=1.60 and, are you ready for this, inefficient pointers=100%!
>>
>> My first thought was to increase the blocking factor (my thinking
>>is with a blocking factor of 1, every pointer must cross a block
>>boundary). I could also increase the capacity somewhat to get the
>>load factor down to 70% or so.
>>
>> What does this august group recommend?
>>
>> Jim
>>
>>
>>---------------------------------
>>Looking for last minute shopping deals? Find them fast with Yahoo! Search.
>>
>>* To join/leave the list, search archives, change list settings, *
>>* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>>
>>
>>
>>--
>>No virus found in this incoming message.
>>Checked by AVG Free Edition.
>>Version: 7.5.516 / Virus Database: 269.19.21/1265 - Release Date:
>>2008-02-07 11:17 AM
>
>------------------------------------------------------------------------
>-------------------------
>Gilles Schipper
>GSA Inc.
>HP System Administration Specialists
>300 John Street, Box 87651 Thornhill, ON Canada L3T 7R4
>Voice: 905.889.3000 Fax: 905.889.3001
>email: [log in to unmask] web: http://www.gsainc.com
>------------------------------------------------------------------------
>-------------------------
>
>* To join/leave the list, search archives, change list settings, *
>* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
--
Roy Brown 'Have nothing in your houses that you do not know to be
Kelmscott Ltd useful, or believe to be beautiful' William Morris
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
