Re: DD_HASHSIZE/MAX on a Baan installation with more than 100,

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).