Hi Brenda,
Is the rule of thumb about the value of GSEMNUM valid for
other systems?
In my personal opinion (which may be wrong!), the "rule of thumb" is not
right.
UV locking is a very complex topic. It is another good reason to recommend
the UniVerse Internals course.
To explain the mechanism briefly, the record lock table has GSEMNUM rows,
each of which can hold at most RLTABSZ locks. The group lock table also has
GSEMNUM rows but each can hold GLTABSZ locks. Given a big system, the
chances are that most record locks also require a separate informational
group lock so it usually makes sense that GLTABSZ and RLTABSZ are the same.
The two tables always have the same number of rows for reasons that I won't
go into here.
The default values are GEMNUM = 97, RLTABSZ and GLTABSZ = 75. That's 7275
entries in each table.
Now the fun bit....
Let's think only about record locks. A particular record lock can only ever
appear on a specific row of the table because the row number is calculated
from the file's inode number and the group number within which the record
exists. Once we know the row number (this is the mysterious number in the
Lmode column of LIST.READU), the system simply scans the row of the record
lock table to look for (a) an existing lock on this record, and (b) a spare
space.
If the record is already locked, the program takes what ever action is
defined by the LOCKED clause or lack thereof. If it is not locked and we
find a spare space in the row, we lock the record. If there is no space,
this is handled just like the record being locked - the lock cannot be moved
to another row.
This is where it all gets horrible. It is unlikely but technically possible
(and easy with contrived demonstration programs) for one row of the table to
be full while all the other rows are completely empty. Ultimately, it all
comes down to statistics about how your application is likely to use locks.
Assuming that it doesn't have some strange pattern about how it locks
records, or lots of modulo 1 files, I tend to work on the assumption that
records will be scattered randomly through the table and you should expect
to be able to (guesswork time) about 60% fill the table before the risk of a
row becoming full becomes significant.
Sizing the tables is not about how many users you have but about how many
concurrent locks you will have. Only you know the answer to this.
The significance of breaking the table into a two dimensional structure (not
the only way to do it) is that the search for a lock has at most RLTABSZ
entries to examine. The downside of this is that you can get the problem of
a row becomming full.
There are some excellent technical papers about sizing the locking tables.
Don't fiddle with the numbers unless you know what you are doing. You can
totally destroy performance.
I have neatly avoided group locks in all of this. There has been recent
discussion on this list about RD and WR group locks. The mysterious
"informational lock" is a mechanism to improve performance of the lock seach
and is nothing more than a count of how many record locks there are in the
group.
Martin Phillips
Ladybridge Systems Ltd
17b Coldstream Lane, Hardingstone, Northampton, NN4 6DB
+44-(0)1604-709200
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/
