Hi all,

OS: HP-UX 11.11
IDS: 7.31.FD8

Question: Would it be insane to set these parameters to values as below
for an IDS instance used by Baan with more than 100,000 tables?

DD_HASHSIZE 20101
DD_HASHMAX 5

Has anyone had any experience with setting DD_HASHSIZE to a value this
high? What would be the implications (memory usage etc)? Are there any
other recommendations?

RoB

RoB said:
> Hi all,
>
> OS: HP-UX 11.11
> IDS: 7.31.FD8
>
> Question: Would it be insane to set these parameters to values as below
> for an IDS instance used by Baan with more than 100,000 tables?
>
> DD_HASHSIZE 20101
> DD_HASHMAX 5
>
> Has anyone had any experience with setting DD_HASHSIZE to a value this
> high? What would be the implications (memory usage etc)? Are there any
> other recommendations?

Make DD_HASHMAX bigger. 5 is very small.
--
Bye now,
Obnoxio

"... no bill is required as no value was provided."
-- Christine Normile

--
This message has been scanned for viruses and
dangerous content by OpenProtect(http://www.openprotect.com), and is
believed to be clean.

Not familiar with Baan installation but we deal with PeopleSoft which is
almost as big & bloated at 55K+ tables.

I use DD_HASHSIZE of 677 (this should be a prime number) and DD_HASHMAX of
10 & I arrived at my setting of 677 by using onstat -g dic | grep dic,
grepping dic just to minimize output.

Last line of output will give you the current # of dictionary entries, use
this # to edit your onconfig file & bounce the server.

Here's a link to the 1st 1000 print #'s

http://primes.utm.edu/lists/small/1000.txt

mjldba wrote:
> Not familiar with Baan installation but we deal with PeopleSoft which is
> almost as big & bloated at 55K+ tables.
>
> I use DD_HASHSIZE of 677 (this should be a prime number) and DD_HASHMAX of
> 10 & I arrived at my setting of 677 by using onstat -g dic | grep dic,
> grepping dic just to minimize output.
>
> Last line of output will give you the current # of dictionary entries, use
> this # to edit your onconfig file & bounce the server.
>
> Here's a link to the 1st 1000 print #'s
>
> http://primes.utm.edu/lists/small/1000.txt


Having these settings:

DD_HASHSIZE 503
DD_HASHMAX 24

Total number of dictionary entries: 11668 (from
onstat -g dic)
Total number of dictionary entries available: 503*24 = 12072.
(almost all buckets are full)
All of the buckets have a few tables that have a "Ref cnt" different
from 0 while the rest of the entries have it set to 0. The instance had
been online for 8 days and used heavily before the stats were taken.

Wouldn't the values above just show us that almost the entire cache is
packed full and that the cache entires are being swapped out by the
Least Recently Used mechanism as new tables not present in the cache
are being accessed? I believe that this is the case and that the cache
is much too small for the amount of tables accessed as only few tables
in the cache are actually referenced again before being swapped out
(thrashing). Therefore I also believe that the "Total number of
dictionary entries:" output wouldn't be adecuate for calculating the
amount of cache entries needed.

Any thoughts?

RoB

The method I gave you was taken from an article written by Art Kagel back
in 1998 so it may or may not be relevant today. Perhaps Art will comment
if he finds this thread.

http://www.prstech.com/tips/art_kagel_tuning_tips.shtml and look at
"Undocumented Config File Parameters/Features".

Beyond this I can't answer your question(s).

thank you for clarifying Art, I wasn't trying to misrepresent what you
wrote. I just made the assumption (wrong, wrong, wrong) that the last
line of onstat -g dic was the target for sizing cache rather than using
that number as a starting point.

mjldba wrote:
> thank you for clarifying Art, I wasn't trying to misrepresent what you
> wrote. I just made the assumption (wrong, wrong, wrong) that the last
> line of onstat -g dic was the target for sizing cache rather than using
> that number as a starting point.

No harm, no foul.

Art S. Kagel