SYSGEN Parameter LOCKDIRWT

[Chris Martin_12]

How do I change the SYSGEN parameter LOCKDIRWT? Is this done through cluster_config.com or by using AUTOGEN?

[Jon Pinkley]

I would put it in SYS$SPECIFIC:[SYSEXE]MODPARAMS.DAT or a file that is being included by MODPARAMS.DAT and then use autogen.

And put a comment there indicating when and why it was changed. You will thank yourself then next time you go back.

Note: It isn't a dynamic parameter, so you are going to need to reboot for it to take effect.

[Chris Martin_12]

Thanks for the quick response.

[Jan van den Ende]

Chris,

pardon my indiscretion, but are you SURE you want to fiddle with LOCKDIRWT? ie, do you KNOW what you are doing?

LOCKDIRWT is great (and practically mandatory) when you have satellites in your cluster, otherwise, just do not meddle with it. It has been some time (V5 timeframe), but we have had "interesting" results with it.

Proost.

Have one on me.

jpe

[Martin Hughes]

I agree with Jan. If you are not 100% sure of what you are doing, then I would suggest you post some details and get some advice on how to manage locking on your cluster. In many circumstances SYSGEN paramater PE1 is a better option than LOCKDIRWT to manage locking.

[Chris Martin_12]

I have a 4-node cluster running OpenVMS 8.2.
All 4 nodes are boot nodes. Three of the nodes have a LOCKDIRWT setting of 1, and one node has a setting of 0. None of these nodes are satellite nodes. I have received complaints regarding slow disk i/o performance specifically on the node with LOCKDIRWT set to 0. This was overlooked last summer when the cluster was upgraded to OpenVMS 8.2.

Hopefully this explains my situation much better.

[Robert Gezelter]

Chris,

You need to check MODPARAMS.DAT (and any files it includes) for a setting for LOCKDIRWT. MODPARAMS will be used next time the system is autogened.

Manually, you can change LOCKDIRWT using either SYSGEN or SYSMAN.

Before doing so, I recommend that you review the OpenVMS Cluster Manual, section 2.6.2, available from the OpenVMS www site at http://www.hp.com/go/openvms (or your friendly CDROM or library shelf).

- Bob Gezelter, http://www.rlgsc.com

[atul sardana]

Dear Chris,

Ya modify it to 1 from 0 manualy its better.
LOCKDIRWT determines the portion of lock manager directory that
this system handles. The default value is usually adequate.

LOCKDIRWT is an AUTOGEN parameter.
Thanks
and give points to this as per satisfaction of your question by this answer.
Atul sardana

[Hoff]

The OpenVMS V8.3 parameter LOCKRMWT might help, as it controls remastering based on system lock activity; it helps control how fast a lock tree will migrate to a system that is more actively using a lock tree. PE1 is another piece of this, and it can help anchor the larger lock trees onto a node, particularly useful if you have larger trees and some flailing, and it can also be set prevent moving lock trees off. As of V8.3, LOCKDIRWT is now the likelihood of mastering a tree -- the definition has changed somewhat from previous releases. Releases V7.2-2 and upwards now also remaster the locks in great huge gobs; much more efficient use of the datagrams and SCS traffic.

[Jan van den Ende]

Chris,

>>>
All 4 nodes are boot nodes. Three of the nodes have a LOCKDIRWT setting of 1, and one node has a setting of 0.
<<<

Well, obviously the warning "do not meddle" was already overdye.

That node witt LOCKDIRWT 0 -has been- meddled with.

Reverse it (set it equal to the others) until you have very good, and well understood, reasons to deviate.
(do not forget to check (& correct) MODPARAMS.

hth

Proost.

Have one on me.

jpe

[John Gillings]

Chris,

> I have received complaints regarding
>slow disk i/o performance specifically
>on the node with LOCKDIRWT set to 0.

If LOCKDIRWT is different on one node, then it must have been changed. There may be a setting in MODPARAMS.DAT - if you're really lucky there may even be a comment saying why it was changed!

In terms of the symptom you're trying to fix, "slow disk i/o", I think it's unlikely that LOCKDIRWT will have any effect. It really only matters where there are multiple nodes contending for the same set of resources, where the locks are being mastered by a (significantly) slower node than the one which is performing the majority of the work. Even if it is involved, you may end up "fixing" this node, by moving the problem to another node.

In general, with your configuration I'd expect to see the same LOCKDIRWT values across nodes, UNLESS there are imbalances in the power of the nodes, or workloads, and even then only really in high locking environments, like RDB or very complex RMS files shared across nodes. If that's the case, most of the time, you're best off just letting OpenVMS figure out where the lock trees should be for optimal performance (simplest way to do that is to let AUTOGEN set all the locking parameters and keep your hands OFF the controls ;-)

Rather than stabbing in the dark, I'd suggest you install T4 and look at the slow node. Try to find the bottleneck. If the problem really is LOCKDIRWT, it will be readily visible as an imbalance in local, incoming and outgoing lock traffic, and/or excessive RWSCS states.