topic Re: RESHASHTBL autogen recommendation in Operating System - OpenVMS

RESHASHTBL autogen recommendation

Jim Lahman_1 — Mon, 20 Nov 2006 13:37:39 GMT

All:

I just performed an autogen on one of my nodes of a 2-node cluster and I received a "strange" recommendation.

Before I go further, let me explain how I perform an autogen. First, I use sysman to save all the active parameters to a file. Then, I perform an autogen using these parameters: SAVPARAMS SETPARAMS FEEDBACK
Then, I use sysman to save all the current parameters to a file.
I then diff the active and current parameters to see what I have to change using sysman.

So, what I see is that autogen recommends LOCKIDTBL change from 29440 to 25549 and RESHASHTBL recommends a change from 143360 to 32768.

It seems to me that the change RESHASHTBL is quite considerable. And, I wonder if it was every correct. Isn't RESHASHTBL supposed to be between 1/2 and 3/4 of LOCKIDTBL? Would you accept the autogen recommendation?

BTW, I attached the diff file for your reading pleasure.

Thanks,

Jim

Re: RESHASHTBL autogen recommendation

Heinz W Genhart — Mon, 20 Nov 2006 13:57:46 GMT

Hi Jim

I think a easyer way to see the differences generated by Autogen is the following:

$ @sy$update autogen savparams setparams feedback
$ Diff/par sys$system:setparams.dat

The second command (Diff) shows all the differences between the old systemparameters and the one you recieved after doing autogen.

Another very important place where you can get informations about last autogen is the file sys$system:agen$params.report. It's a text file, so you can just type it.

hope that helps

Regards

Heinz

Re: RESHASHTBL autogen recommendation

comarow — Mon, 20 Nov 2006 16:52:49 GMT

You've already been told that you're doing a lot of extra commands.

It might be better not to use feedback, as it will protect you from running autogen without at 24 hours of feedback.
Just use
@sys$update:autogen savparams setparams

Then
$set term/width=132
$Diff/Par sys$system:setparams.dat

That said, the reason your RESHASHTBL
probably has to do with a lot of RMS
and file system locking. You might
wish to get a handle on your locking
activity.

You can actually look at the agen$feedback.dat file. It's simply an
ASCII file. It will show you the locks used
and the amount of your RESHASHTBL used.
It's not magic, mostly just DCL.

Have fun.

Bob

Re: RESHASHTBL autogen recommendation

Wim Van den Wyngaert — Tue, 21 Nov 2006 03:56:59 GMT

The advantage of the "Jim" method (which also is the "Wim" system) is that you get a list of all changes, even the ones made by hand without autogen.

Wim

Re: RESHASHTBL autogen recommendation

Wim Van den Wyngaert — Tue, 21 Nov 2006 04:08:20 GMT

The LOCKIDTBL is the number of entries by which the lock id table is extended. This each time it runs out of locks ids.

The RESHASHTBL is the number of RESOURCES in the hash table. This table has a fixed number of entries. The guideline says by average 4 locks exist for every resource. But this depends on what you are doing. And autogen should know what you are doing.

Wim

Re: RESHASHTBL autogen recommendation

Volker Halle — Tue, 21 Nov 2006 06:19:50 GMT

Jim,

RESHASHTBL should be about 4 times larger than the total no. of resources used in the system (see SYSGEN> HELP SYS_P RESHASHTBL).

You can easily obtain the no. of resources in use on your system with $ MONI LOCK (look at Total Resources) or even with SEARCH SYS$SYSTEM:AGEN$PARAMS.DAT RESOURCES_INUSE

Maybe your system load (in terms of no. of resources) has decreased. The LOCKIDTBL decrease suggested by AUTOGEN may point in the same direction.

How the resource hash table works:

If a new lock is enqued, the system needs to find out, if a resource with the given name already exists in the cluster. The resource name is hashed and used as a lookup key into the resource hash table (on the directory node for this resource name). The has chain is being followed and every resource in that hash chain is checked sequentially. All resources in a given hash chain have the same hash value. If the RESHASHTBL value is (much) too small, the system needs to spend more CPU sequentially searching through the has chain.

Volker.