Like the original poster we don't have any locking issues and since it has been 2-3 years since I took the UV Internals course and about 2 years since the last time I had to change UV settings, I just didn't remember the GSEMNUM setting default and recommendation.
Our license count was originally less than the GSEMNUM value of 97, we've slowly added licenses until we got to 117. We'll have to keep this in mind the next time we add licenses. Definitely will be something to look at, if we ever switch to device licensing. Brenda -----Original Message----- From: Martin Phillips [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 02, 2008 9:05 AM To: [email protected] Subject: Re: [U2] locking question 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/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
