Dedicating processor to record locking

[Randy Hancock]

We are installing a new 4 processor ES47 which will essentially replace a 4 year old ES40. We have been told by a consultant that our software does an inordinately high amount of record locking and that we may benefit by dedicating one of the processors solely to that function.

Questions:

Is this really possible?
If so, how?
Lastly, is it a wise move?

Thanks for your input...

[Eberhard Wacker · Accepted solution]

Hi Randy,

a) Yes, sure, they told no lies, it is possible.
b) You have to set the sysgen paramater LCKMGR_MODE to the value of the CPUs which shall be available as long as 1 CPU shall be reserved for the new LCKMGR_SERVER process.
c) The question of wisdom: the Dedicated CPU Lock Manager might be senseful for you to reduce too much MP_SYNCH overhead but the advantages/disadvantages depend on your applications behaviour.

In your case: if you set the sysgen parameter LCKMGR_MODE to 4 then the Dedicated CPU Lock Manager is active as long as there are 4 available/running/active CPUs. Then it consumes 1 CPU for its own (because running on priority 63) and you have only 3 for the rest of all.
In general I would activate it only having more than 6 CPUs (but as already told it depends mainly from your applications and system workload).

Depending on your system/cluster configuration it might also be worthy to think about the settings of the LOCKDIRWT sysgen parameter.

Have a look at http://h71000.www7.hp.com/doc/73final/6491/6491pro_015.html (or the corresponding documentation of the latest VMS versions).

Cheers
EW

[comarow]

The good news is you can turn it on or off dynamically. It may well help you. That cpu must not have any fast path devices attached to it.

The rule of thumb is 5 or more cpus. However, I have recommended it to 4 cpu heavy locking systems, and it has helped.
An ES47 can be altered to support an additional CPU, and that would make much more sense. Even with 4 cpus it might be very viable, but I would plan on adding another cpu for that dedicated purpose.

BTW, what are your locking numbers during say a 15 minute peak period of time.

In sys$examples there is a file called spl.com that lets you see where the spin locks are being held.

[Hein van den Heuvel]

Yes it is possible to dedicate a cpu to the lock manager by the steps outlines earlier, but it is probably NOT a wise move.

The dedicated lock manager is extra useful in (clustered) high contention environment with CPU's to spare and with the lock manager already spending at least 1/2 a cpu in kernel/interupt/mpsync time.
I suspect you do not meet a single one of those requirements, but will happiliy be proven wrong.

Why don't we step back a little.
First... which exact VMS version?
What is 'inordinate'? a million/second?

and WHAT PROBLEM ARE YOU REALLY TRYING TO SOLVE?

Do you have a reason to believe those records locks are bad? Could they not simply be a reflection of a lot of work bing done?

Does that inorinate rate roughly match your expectation based on the work rate? For example, if the application is processing N items/second, is teh lock rate 2*N (probably great) or 10*N (which coudl be fine) or is it 1000*N indicating a serious application issue. In the latter case, why waste time optimizing locks, but focus on not doing locks instead!

Next You talk about 'record locking' is that per chance a reference to RMS record locking?
Or are we talking RDB or some other DB/record manager?

What is the application doing when it generates that high amount of lock traffic?

If it is RMS, are we sure we are talking RECORD locks, or could we be talking bucket lock?

If it is and application reading through and rms (indexed?) file, maybe you need to investigate using the (relatively recent) rms NO-QUERY-LOCK option?!

Looking forward to read a more pertinent problem description!

Hope this helps some,
Hein.

[Randy Hancock]

Thanks for all your responses. I am primarily a programmer/developer with about 17 years of VMS experience (Basic and Dibol), but try to dabble in some of the systems management things when the occasion arises.

Our systems manager primarily handles all of the numerous Windows based servers, so between us and two other programmer/developers we are attempting to learn as much as we can to configure this new system to our needs.

Our current platform is an ES40 with 3 cpus running OpenVMS 7.2-1. Problems we have experienced over the last year are maxed out CPUs (at or near 300% for several hours at a time), 3 or 4 crashes resulting from spin waits, and increased usage by heavy I/O processes (iCARaS, CONNx).

HP consultant was the one who recommended dedicating a process to locks.

I do not have numbers to post here at this time...will have to do that at a later date. Locks are RMS (through Dibol), and for the most part, when I have examined or modified the code, locks are being used quite judiciously. They are generally placed only when the intent is to modify the record.

New system will be running 7.3

And what is the NO-QUERY-LOCK option?

Again, thanks to all for your help...it has started us in the right direction to make our decision.

[Hein van den Heuvel]

RAB$V_NQL

It is a methos to not get a record lock at all, versus the NLK option which just tells RMS not to keep a record lock, but will aquire and release a record lock every time.

This is just a WAG. There is no clear indication that you have a record locking problem, but maybe, just maybe....

RMS Ref Man:

See RAB$L_ROP_2
http://h71000.www7.hp.com/doc/73final/4523/4523pro_012.html#rop_2

VMS Guide to file:


File Sharing and Buffering
7.2 Record Locking
Table 7â 5 Methods Available for Specifying No Query Record Locking



So when you say 300% CPU... was that all KERNEL? Lots of MPSYNC? EXEC mode?
How many IO/sec? Did MONI RMS give useful usage rates? How about my RMS_STATS (freeware) ?

Did you ever try my RMS_TUNE_CHECK on some critical files? Duplicate key chains can easily cause excessive IOs (hits is XFC cache) and excessive buckt lock rates.
Again... no reason to believe this is the problem but you should everify that it is not the problem just in case.

Good luck!
Hei

[Jan van den Ende]

Randy,

apart from the previous advises (especially read and re-read Hein on the KIND of lockings and the NEED of locking!) I think the single most useful advise I can give you:
Please, upgrade to V7.3-2!! (and that, to patch UPGRADE-0400).
Some issues, involving SPINWAIT during heavy locking have been resolved.
CPU max out with locking sounds unpleasant as well. Caching has improved A LOT from 7.2-x to 7.3, but there were some issues with vanilla 7.3. Besides: 7.2(-x), 7.3, and 7.3-1 are no longer supported.

How do you intend to move from ES40 to ES47?
I am a great proponent of (even temporarily) a cluster, and gradual move over.
(btw, are you ADDING the ES47, or is there a trade-in? Even in the latter case, a temporary cluster license is a mighty good
idea!

Aside: is your CONNX behaving well? I HAVE met the situation where each new query involved generating the whole data description again, so double-checking can be worthwhile!

Proost.

Have one on me.

jpe

[Randy Hancock]

Thanks again for your help. Yes, we are clustering the ES47 and ES40...will be keeping both. ES47 is already at v7.3-2, will have to check on patch upgrade 0400.

As for CONNX, will have to look into your suggestions.