A semaphore can be defined as access to a shared data object for multiple processes. They give a process a "license" to lock a resource such as record, SHMEM slot, latch, etc. Progress uses these semaphores in two groups: login and user.
- The login semaphore is the resource every process needs to connect to the database and it is only used for that purpose.
- The user semaphore is used by a user process already connected to the database to lock a record or other resource.
The following Article contains a nice schematic together with further documentation references:
How does Progress use semaphores?Both types of these semaphores are put into the same pool and we can refer to this pool as a "semset". The number of semaphores within this set is determined by the Maximum Number of Users (-n) and Maximum Number of Servers (-Mn) startup parameters for each database.
How to and Why Use Multiple Semaphore Sets (-semsets option)? With an Enterprise database license and when the
-spin database startup parameter is used, the database engine will use semaphores as well as latches.
- Semaphores are used for "long term" waits (such as a wait for a record lock) regardless of the setting of -spin.
- -spin latches cover "short term waits" which are the latches used by the database storage engine to protect critical sections of code (usually shared memory lookups and updates).
The Database Storage Manager uses semaphores for 6 specific things:In conjunction with
spin locks, semaphores synchronize the activities of server and self-service client processes that are connected to a database.
1) To regulate access to the user table (-n, -Mn) during database login/logout.
None of the other locking mechanisms Progress uses work until a user table entry has been allocated.
2) To stop a process when it is waiting for a schema lock.
All Progress really needs is a system call to stop a process and another one to start it again.
There is no other suitable system call for this. The Database Storage Manager uses semaphores in spite of the fact they are not designed for it.
3) To stop a process when it is waiting for a record lock.
4) To stop a process when it is waiting for another process's transaction to end.
Transaction waits are a result of trying to access a record that has been deleted by an as yet incomplete transaction.
5) To stop a process when there is an internal medium-term resource lock conflict.
An example of this is when an I/O operation is in process and Progress must wait for it to complete before accessing the buffer contents.
6) To stop a process (when -spin is not used) when there is a short-term "latch" conflict while attempting to lock a data structure in shared memory.
When -spin is used, instead of semaphores, Progress does shared-memory latches with its own high-speed, low overhead, spinlock code.
How to determine when there are too many semaphore operations?To determine if semaphore contention could be a problem on the system is “
sar –u”. If %sys is higher than 25%, then there may be a semaphore contention problem marked by performance degradation as more concurrent users are added (-n).
Semaphore contention can also be identified through the PROMON R&D menu:
$ promon dbname > R&D > Activity Displays > Other
Where, the waits on semaphore field, will identify if a semaphore is the resource users are waiting on.
Optimum numbers for this option will vary from system to system.
To locate the semaphores the database is using, semaphore id by user can be correlated with "$
ipcs -sa" :
$ promon dbname > R&D > debghb > 6 (hidden option) > 16 semaphores
$ promon dbname > R&D > 6. Advanced R&D > 16 semaphores
This will yield three columns:
User (user number)
Id (number of semset)
Num (sem number within set)
What can you do to influence semaphore operations?Apart from tuning the kernel semaphores, only two things can be done to change the number of semaphore operations:
1) Use -spin to eliminate having to use semaphores for "short term waits" as outlined above, when using an Enterprise database license.
What is the -spin parameter? 2) Change the application to reduce the number of record lock conflicts.
