Is there anyway we can increase the threshold of READU locks.

Currently I am getting below error.

READU threshold reached, lock on xxx denied!
Program "ED": pc = 69BA, READU threshold reached, lock on "xxxxx" den
ied!

Im not sure by 100% but the parameter RLOWNER in uvconfig should be the correct setting. However the UV manual suggest to be careful by increasing this value because it affects disk io performance.

We had the same message some time ago, but it was because of a wrong programming in a huge update process in not corretly release the lock after readu, so i didn't touch this setting..

Also it could be worth to take a look at RLTABSZ in the Administering Universe Manual...

Best regards

Thomas

------------------------------
Thomas Ludwig
System Builder Developer
Rocket Forum Shared Account
------------------------------

The RLTABSZ uvconfig parameter sets the number of readu locks which can set in a given group lock bucket. Do you understand why you are hitting the current limit? Is it expected to have a lot of READU locks active in a single group lock bucket? Does the application use transaction semantics? Are a large number of READU locks being set on a Type 1 or Type 19 file? Or a file with a small modulus? 

Is there anyway we can increase the threshold of READU locks.

Currently I am getting below error.

READU threshold reached, lock on xxx denied!
Program "ED": pc = 69BA, READU threshold reached, lock on "xxxxx" den
ied!

hello Shubham,

I suppose you use Transaction Processing (TRANSACTION BEGIN/COMMIT/ROLLBACK) in your basics.

Do you work with the default uvconfig set of param for locks management ? 

So : Here are my habits :

RLTABZ Sets the number of update record lock entries in a group lock semaphore set.  The size of the bucket to maintain RECORD locks.

GLTABSZ Sets the number of group lock entries in a group lock semaphore set. The size of the bucket to maintain GROUP locks. 

GSEMNUM Sets the number of group lock semaphore sets. The number of bucket !! (GL/RL) 

Instead of increasing the size of the buckets, it is much better to increase their number. By doubling the number of buckets, you double the overall capacity (GL/RL).  While maintaining performance for other sessions. By proposing less or no collision or waiting in group semaphores. 

Be careful, GL's semaphores are managed with hash access, the value of GSEMNUM must be a prime number!

And nothing stops you from increasing the value of RLTABSZ too. 

I hope this help.

Is there anyway we can increase the threshold of READU locks.

Currently I am getting below error.

READU threshold reached, lock on xxx denied!
Program "ED": pc = 69BA, READU threshold reached, lock on "xxxxx" den
ied!

Thank you for the quick response Neil and Thomas.  I will try changing the numbers of RLTABSZ in uvconfig.

Also, we need to commit only if all the transactions are successfully completed. In case of any failure to any one transaction we need to rollback all the transactions therefore, a lot of records are required to be locked.

------------------------------
Shubham Nigam
Rocket Forum Shared Account
------------------------------

A little more detail on Neil's answer.

GSEMNUM specifies the number of lists of depth GLTABSZ for group locks. The group lock table holds a maximum of GSEMNUM by GLTABSZ entries. 

The READU lock table is GSEMNUM by RLTABSZ which limits the maximum total  entries.

The row of entries for a group/read lock is calculated by MOD(inode + group address, GSEMNUM). A directory type file, type 1 and 19, use a group address of 1 for all records. This forces all locks to be behind a single group table entry. The group address in hashed files is some multiple of 512 * separation. This provides a good reason for selecting a GSEMNUM that is a prime number and certainly not a multiple of 2. Note that a file will have a modulo number of distinct group addresses, and a small modulo will limit the maximum number of readu locks to modulo * RLTABSZ. Exceeding the number of locks (by any user for any file) in a single readu lock table row will produce the READU threshold exceeded message and failure.

A semaphore controls access to a row in the group lock table and its corresponding readu lock table. There are GSEMNUM semaphores for the lock tables.

A group lock is identified by node (zero for local host), device and inode numbers, and group address. A read lock adds the ID to the identification. 

An active group lock will have RD for a read and WR for a write. Up on completion of the active read/write, the group lock will revert to an IN, informational, group lock for letting the locking mechanism know there are extant RU/RL locks, or will be removed if there are no row locks in the group signature. A simple database read will only produce a group lock with no entry in the readu lock table. A (questionable) rule of thumb of 9 reads per write may help estimate the number of group locks to readu locks.

A readu lock will always have an associated group lock. An active read/write will have the corresponding RD or WR lock, and a quiescent readu lock will have an associated IN lock (assuming no other activity in that group signature). 

These details support a number of ways to increase the number of available readu locks:

1. Increase the file modulo, permitting more GSEMNUM table entries to participate in the modulus of the group address. Note that the inode simply affects the "starting" point for the first group so multiple files will more evenly distribute. This also is only helpful for a file with a "small" modulo (less than GSEMNUM).
2. Increase GSEMNUM to allow more RLTABSZ size rows to participate.
3. Make GSEMNUM prime to help distribute the group address across more row entries in the lock tables.
4. Increase RLTABSZ to allow more locks per readu table row.

Your question comes from transactional updates that hold all of the locks until the COMMIT. That suggests a sufficiently large file that (1) above does not apply, but 2, 3, and 4 should provide the opportunities to alleviate the problem.

Hello Mark, 

I thank you for a deep detailed explain of  lock algo and file/uvconfigs implications.

May I request the same explain for uv r12/r14 (and as I understand, Unidata too)? 

I'm really asking for it to switch correctly to the new method. 

One more time, Thank you very much. 

Hi Manu,

UniData's locking mechanism and internal structures are different to those of the old UniVerse locking structures. UniVerse now uses the same structures in 12 and 14. I do have some internal presentations I did on this when the change was made. When I get some free cycles I will look to make those presentations available externally via a knowledge base article. I'm pretty sure Mark had already left Rocket before I did those presentations so don't think he has them.

Thanks,

A little more detail on Neil's answer.

GSEMNUM specifies the number of lists of depth GLTABSZ for group locks. The group lock table holds a maximum of GSEMNUM by GLTABSZ entries. 

The READU lock table is GSEMNUM by RLTABSZ which limits the maximum total  entries.

The row of entries for a group/read lock is calculated by MOD(inode + group address, GSEMNUM). A directory type file, type 1 and 19, use a group address of 1 for all records. This forces all locks to be behind a single group table entry. The group address in hashed files is some multiple of 512 * separation. This provides a good reason for selecting a GSEMNUM that is a prime number and certainly not a multiple of 2. Note that a file will have a modulo number of distinct group addresses, and a small modulo will limit the maximum number of readu locks to modulo * RLTABSZ. Exceeding the number of locks (by any user for any file) in a single readu lock table row will produce the READU threshold exceeded message and failure.

A semaphore controls access to a row in the group lock table and its corresponding readu lock table. There are GSEMNUM semaphores for the lock tables.

A group lock is identified by node (zero for local host), device and inode numbers, and group address. A read lock adds the ID to the identification. 

An active group lock will have RD for a read and WR for a write. Up on completion of the active read/write, the group lock will revert to an IN, informational, group lock for letting the locking mechanism know there are extant RU/RL locks, or will be removed if there are no row locks in the group signature. A simple database read will only produce a group lock with no entry in the readu lock table. A (questionable) rule of thumb of 9 reads per write may help estimate the number of group locks to readu locks.

A readu lock will always have an associated group lock. An active read/write will have the corresponding RD or WR lock, and a quiescent readu lock will have an associated IN lock (assuming no other activity in that group signature). 

These details support a number of ways to increase the number of available readu locks:

1. Increase the file modulo, permitting more GSEMNUM table entries to participate in the modulus of the group address. Note that the inode simply affects the "starting" point for the first group so multiple files will more evenly distribute. This also is only helpful for a file with a "small" modulo (less than GSEMNUM).
2. Increase GSEMNUM to allow more RLTABSZ size rows to participate.
3. Make GSEMNUM prime to help distribute the group address across more row entries in the lock tables.
4. Increase RLTABSZ to allow more locks per readu table row.

Your question comes from transactional updates that hold all of the locks until the COMMIT. That suggests a sufficiently large file that (1) above does not apply, but 2, 3, and 4 should provide the opportunities to alleviate the problem.

hi Jonathan

I can't wait to read you :-).

Manu,

Sorry it's taken me some time to reply, I had forgotten about this. The attached pdf is of the internal presentation I did on the locking changes in UniVerse a while ago (2018).

Thanks,

Manu,

Sorry it's taken me some time to reply, I had forgotten about this. The attached pdf is of the internal presentation I did on the locking changes in UniVerse a while ago (2018).

Thanks,

Hi Jonathan,

Thank you for this. 

Do you have the same regarding how to properly qualify the udconfig/uvconfig GLM param ?

With kind regards