Please clarify what ENQLM is

[John McL]

What exactly ios ENQLM and what is teh recommended value on Alphas?

The System Manager's Manual vol 1 says of ENQLM (on Table 7.9, pg 244) ...

"Limits the number of locks a process (and its subprocesses) can own." (The v7.3-2 version of this manual said in table 7.8 that the default on Alpha is 2000.)

The documentation for AUTHORIZE says ...

"/ENQLM=value - Specifies the lock queue limit for the ENQLM field of the UAF record. The lock queue limit is the maximum number of locks that can be queued by the user at one time. The default is 200 on VAX systems and 4000 on Alpha and I64 systems."

The System Services manual says, under details for SYSCREPRC ...

"PQL$_ENQLM Lock request quota. This quota limits the number of lock requests that a process can queue."

and for SYS$GETJPI, ...

"JPI$_ENQLM - Returns the lock request quota of the process, which is a longword integer value."

and for SYS$GETUAI ...

"UAI$_ENQLM - Returns the lock queue limit"

QUESTIONS

1 - which definition is correct? (A limit on locks in the the ENQ and/or DEQ queue or the total number of locks that can be owned? - or are they the same?)

2 - What is the recommended default value on Alphas with plenty of memory?

3 - (Related question on lock processing) Why is it that in a loop that just does an SYS$ENQW and SYS$DEQ we see a continual increase in the number of locks being consumed rather than staying at a small number ((i.e. JPI$_ENQCNT decreasing)?

[Hein van den Heuvel · Accepted solution]

1 - which definition is correct?

The clearest definition for me is: "the total number of locks that can be owned". In what state they are (being ENQues, DEQued or CoNVerted is less relevant IMHO

2 - What is the recommended default value on Alphas with plenty of memory?

Although each locks consumes a little memory, this really has NOTHING to do (anoymore) with the total memory in the box. It has everything to do with the application usage of locks which 'depends'.
This is a 'quota' aka fools-guards.
You have to have enough. More then enough does not help or hinder.
Too little will likely cause the application to break.
Too much more may allow an errant application to consume too much resources but does not cost anything if the application behaves, so typically you want to err on the save side.

And example:
Application reading one record at a time from an indexed files. This will need 1 lock for the RMS record lock, but will also typically consume one lock for each RMS buffer used: typically 5 - 20. So on ENQLM of 100 or so will do (an extra one for the file lock, some other files, and so one)
Now an application which feels it needs to lock all records each holding for a customer. (it should probably just lock the customer record, not the holdings). It will need as many record locks as a customer may have holdings. 100? 1000? 10,000? Entirely up to the application. Nothing to do with memory.

Now it is _possible_ to design an application which for example caches as many records as it can get locks, or 1/10 of ENQLM or some such. Such application could get a perfomance benefit from an high ENQLM... but such application had batter document that behaviour.

>>> 3 - (Related question on lock processing) Why is it that in a loop that just does an SYS$ENQW and SYS$DEQ we see a continual increase in the number of locks being consumed rather than staying at a small number ((i.e. JPI$_ENQCNT decreasing)?

Because there is a coding error in the application. No if's or but's about it.
The applicaion is broken! Most likely on the DEQ side. Is the status checked?
Just use ANAL/SYS... SET PROC ... SHOW PROC/LOCK.

Cheers,
Hein






3 - (Related question on lock processing) Why is it that in a loop that just does an SYS$ENQW and SYS$DEQ we see a continual increase in the number of locks being consumed rather than staying at a small number ((i.e. JPI$_ENQCNT decreasing)?

[John Gillings]

John,

Mostly what Hein said, except to point out that you can set ENQLM to "unlimited" for a process by setting it to 32767. On the other hand, if you haven't found the bug in your ENQ/DEQ test loop, that's probably not a good idea! Check passing mechanismsm and status codes.

[John McL]

Thanks for your comments re points 1 and 2.

The person who has been working with the code that loops through SYS$ENQW and SYS$DEQ has been absent today. With any luck I'll have an update on the sitaution tomorrow.

[Robert Gezelter]

John,

Some foundational technologies (e.g., databases) do large amounts of locking for a variety of reasons.

I suspect that the historical reasons for the increase in values from VAX to Alpha is partially a reflection that these tools have become more prevalent on faster, larger memory capacity systems.

With regards to locks seeming to be consumed, I concur with checking the code and status returns. I also observe that SDA can extract the current state of the lock database.

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

[Hoff]

1: http://labs.hoffmanlabs.com/node/492
2: varies by application.
3: that's called a "bug" or (more specifically) a "leak".

[John McL]

Thanks for the responses. Our understanding is better now.

The problem mentioned in item 3 was finally traced a bug in some in-house code that's about 5 years old. It was creating a new lock every time when it should have been reusing the one lock. It had never previously been stressed to the point of exceeding anyone's ENQLM, which is why this whole question arose.

[Steve Reece_3]

One application that I used to be involved with took out locks when it really didn't need them, though the designers didn't realize it (much as the ones here). having had HP look at the performance of the systems (which had really nose-dived), it emerged that the level of locking was quite beyond anything that our HP expert had encountered before - the SDA lock plugin has a circular buffer that counts up to 32767 locks and we were well blowing that!

Moral: locks may take up only a little memory but taking too many of them out will batter performance like an oversize baseball bat.