Peter, Thanks for digging for more information. It sounds to me like RLOWNER was set to the RLTABSZ, effectively saying that every read lock associated with a given semaphore group could be a READL lock. Since every READL lock would displace a possible READU lock, you could, with 300 separate processes accessing the same record in the same file, make it impossible anyone to get a READU lock in the same semaphore group.
Likewise, by having a smaller number of processes perform READL's on multiple files, but coincidently use the same semaphore group, you could obtain the same blocked condition. Admittedly, both conditions seem unlikely, and if you are running a system with that many READL locks routinely active, "why bother?", no one is ever going to be updating anything! I would think that a better rule would be to limit the value of RLOWNER to 50% of RLTABSZ, just to keep some room for quasi-normal function if some developer decided to create an application that used a READL on a specific file/record to communicate to other processes in ill-considered ways. Cheers, Rick On Aug 15, 2013, at 5:19 PM, Peter Cheney <peter.che...@firstmac.com.au> wrote: >> From my UV9.4 internals manual in the UV data structures chapter... > > Sizing lock tables... > > - The file lock table has FSEMNUM (default 23) rows, each with FLTABSZ > (default 11) entries. > > - The group lock table has GSEMNUM (default 23) rows, each with GLTABSZ > (default 300) entries. > > - The record update lock table has GSEMNUM (default 23) rows, each with > RLTABSZ (default 300) entries > > Each row in each table has a semaphore associated with it. > > > > The whole chapter talks about semaphore collisions and retries etc when > dealing with locks. Further on is another section also called Sizing lock > tables that says... > > Increasing GSEMNUM spreads the concurrent group locks across more rows, > reducing the average count of group locks per semaphore. The shorter list > reduces the amount of time the semaphore needs to be held to process the > tables. This reduced time not only reduces the probability of collision but > also reduces the number of retries before the semaphore becomes available. > > Reducing the processing time also reduces the probability that the time slice > will expire while the user owns the semaphore. If the time slice expires > while the semaphore is held, other users may put significant load on the > system trying to get the semaphore. > > > > Further on it says... > > Shared file locks and shared record locks are handled as linked lists > > > >> From the UV9.3 system administration manual... > > RLOWNER - Sets the number of lock owner entries that are maintained for > shared (READL) locks in a group lock semaphore set. Great care should be > exercised when changing this parameter. The performance of the disk i/o > subsystem may be profoundly affected. > > > > I've always been advised that the default RLOWNER value of 300 is too big and > should be reduced to about 120. > > > > So does the above mean that RLOWNER controls the number of entries in a > semaphore? > > HTH > > Cheers > > Peter > > > > > > -----Original Message----- > From: u2-users-boun...@listserver.u2ug.org > [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Rick Nuckolls > Sent: Friday, 16 August 2013 2:33 AM > To: 'U2 Users List' > Subject: Re: [U2] Universe Configuration -- > > > > More research than anything else. We are having an occasional performance > problem with one file, and I was checking the lock tables and tuneables. And > realized that I might be misinterpreting "RLOWNER", since "smat-a" does not > list out a separate table for it, at least that I could see. > > > > On some earlier versions of Solaris & UV, it is possible to configure the > lock tables to be too large for the memory segment, and uvregen will balk. I > have not played with this at the current releases. I agree that the default > for RLOWNER of 300 does not sound very taxing, but if it really is 300 table > entries for each group semaphore x 40 bytes or so, that could add up to a > chunk of wasted space. > > > > + Okay, I tested a couple of these changes: Changing RLOWNER from 300 > > + to 400 has no effect on the segment size output of uvregen. Changing > > + RLOWNER to 2000 also has no effect. Changing the RLTABSZ by 100 upped > > + the usage by 1.7 M ( GSEMNUM=97). Likewise, bumping GSEMNUM by 10 to > > + 107 bumped the segment size by 0.52 M. (No units, since it is not > > + reported by uvregen. It could be bytes or words.) > > > >> From this, I deduce that RLOWNER, does not affect the size of any tables, >> rather it might be a limit on the number of users that can concurrently lock >> a single record using the READL statement. Not sure what else it could be. > > > > -Rick > > > > -----Original Message----- > > From: > u2-users-boun...@listserver.u2ug.org<mailto:u2-users-boun...@listserver.u2ug.org> > [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Aaron Titus > > Sent: Thursday, August 15, 2013 7:20 AM > > To: U2 Users List > > Subject: Re: [U2] Universe Configuration -- > > > > I wouldn't be concerned about the default value being too high. The main > reason to modify the tunables is to increase them when you are hitting a > limit. Years ago, when kernels had very little shared memory in their > out-of-the-box configuration, the tunables were set quite low so that > Universe would function after installation. With decent sized concurrent > users (or lots of phantoms) it would frequently need to be increased. The > defaults now are more reasonable. smat -a will show all the lock tables; > with that you can see where you are at a given point in time. Increase it if > you are reaching the limit but there is no reason to lower them if you are > not. > > > > > > *Aaron Titus* > > Senior Software Engineer > > F.W. Davison & Company, Inc. > > 508-747-7261 x245 > > ati...@fwdco.com<mailto:ati...@fwdco.com> > > > > > > > > On Wed, Aug 14, 2013 at 6:23 PM, Rick Nuckolls > <r...@lynden.com<mailto:r...@lynden.com>> wrote: > > > >> The link to SQL makes some sense. > >> > >> My original thought was RLOWNER was to Shared Locks (RL) as RLTABSZ is > >> to Exclusive (RU) locks, but the default (300) seemed a little high > >> for tracking RL locks, especially if that is 300 x GSEMNUM. Also, the > >> only reporting that I can find is as a "RL" entry in the LIST.READU > >> output, with multiple locks on a single record appearing as a single > >> record lock in the "Active Group Locks" list. Interestingly, "smat > >> -r" shows the user info for the shared locks, but not the exclusive > >> locks. This makes me wonder if the configuration value is still > >> relevant, or if the tables have been combined. > >> > >> In that there seem to be very minimal uses for shared locks outside of > >> SQL, 300 seems a bit high for the average Legacy PI/OPEN install. > >> > >> Thanks, > >> Rick > >> > >> -----Original Message----- > >> From: >> u2-users-boun...@listserver.u2ug.org<mailto:u2-users-boun...@listserver.u2ug.org> >> [mailto: > >> u2-users-boun...@listserver.u2ug.org<mailto:u2-users-boun...@listserver.u2ug.org>] >> On Behalf Of Phil Walker > >> Sent: Wednesday, August 14, 2013 2:00 PM > >> To: U2 Users List > >> Subject: Re: [U2] Universe Configuration -- > >> > >> The RLOWNER parameter relates to record shared locks and were > >> introduced to Universe when the SQL syntax was. The value determines > >> the number of slots available to hold the user information of the > >> processes holding the shared locks. If any shared locks are held > >> against a record an exclusive lock, READU or FILELOCK, EXCLUSIVE will > >> fail or take the locked clause. If you do not use SQL or specifically > >> request a READL lock in basic then you can basically ignore it I believe >> from memory. > >> > >> Regards > >> > >> Phil > >> > >> -----Original Message----- > >> From: >> u2-users-boun...@listserver.u2ug.org<mailto:u2-users-boun...@listserver.u2ug.org> >> [mailto: > >> u2-users-boun...@listserver.u2ug.org<mailto:u2-users-boun...@listserver.u2ug.org>] >> On Behalf Of Rick Nuckolls > >> Sent: Thursday, 15 August 2013 6:06 a.m. > >> To: 'U2 Users List' > >> Subject: [U2] Universe Configuration -- > >> > >> Can anyone provide a cogent explanation of the RLOWNER configuration > >> parameter in UV? How does it relate to the GSEMNUM and GLTABSZ/RLTABSZ? > >> What are the contents & duration of an associated entry? Is there any > >> way to determine the number in use (as opposed to the configured number)? > >> > >> The manual's explanation is a bit short. Thanks, > >> > >> Rick Nuckolls > >> > >> _______________________________________________ > >> U2-Users mailing list > >> U2-Users@listserver.u2ug.org<mailto:U2-Users@listserver.u2ug.org> > >> http://listserver.u2ug.org/mailman/listinfo/u2-users > >> _______________________________________________ > >> U2-Users mailing list > >> U2-Users@listserver.u2ug.org<mailto:U2-Users@listserver.u2ug.org> > >> http://listserver.u2ug.org/mailman/listinfo/u2-users > >> _______________________________________________ > >> U2-Users mailing list > >> U2-Users@listserver.u2ug.org<mailto:U2-Users@listserver.u2ug.org> > >> http://listserver.u2ug.org/mailman/listinfo/u2-users > >> > > _______________________________________________ > > U2-Users mailing list > > U2-Users@listserver.u2ug.org<mailto:U2-Users@listserver.u2ug.org> > > http://listserver.u2ug.org/mailman/listinfo/u2-users > > _______________________________________________ > > U2-Users mailing list > > U2-Users@listserver.u2ug.org<mailto:U2-Users@listserver.u2ug.org> > > http://listserver.u2ug.org/mailman/listinfo/u2-users > > ------------------------------------------------------------------------------- > Note: > This email (inc all attachments) is for the use of the intended recipient(s) > only. > Privileged or confidential information may be contained in this > communication. If you have received this email in error, please notify the > sender immediately and then delete all copies of this message from your > computer network. If you are not the intended recipient, you must not keep, > use, disclose, copy or distribute this email without the author's prior > permission. If you are the intended recipient and you do not wish to receive > similar electronic messages from us in future, then please respond to the > sender to this effect. > We have taken precautions to minimise the risk of transmitting software > viruses, but advise you to carry out your own virus checks on this email and > its attachments. We do not accept liability for any loss or damage caused by > software viruses and do not represent that this transmission is free from > viruses or other defects. > Firstmac Limited (ABN 59 094 145 963) (AFSL 290600) > ------------------------------------------------------------------------------- > _______________________________________________ > U2-Users mailing list > U2-Users@listserver.u2ug.org > http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
