What is a “semset” ?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.
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. Any auxiliary process need to be included in the “-n” count, i.e. APWs, AIW,BIW, WDOG, replication process, online backup, extra promon sessions, etc. As we add additional auxiliary process, we need to add more to the -n values to accommodate them.
How to and Why Use Multiple Semaphore Sets (-semsets option):Since a single semset has been implemented from the beginning of Progress time, one potentially major caveat in using only one, is that at any given time only one process can have access to this pool. This is regardless of whether the process is logging into the database, or is performing a normal processing type operation. If multiple processes are queuing for access to one pool, this is a potential bottleneck. Linux did not have this problem, thus there is no performance gain using multiple semsets on Linux.
To further cloud the issue, Progress has always successfully started a server process even if the kernel does not have enough semaphores available for each process defined by the -n and -Mn parameters. In this case we take as many as the kernel can offer and round robin them among the user processes sharing this access by both login and user processes. At this point we have a sort of "double contention" going on. A symptom of being low on kernel semaphores is a "warning: only x available wait semaphores" in the beginning of the database .lg file.
The latter problem can only be addressed by tuning the kernel to have more semaphores available. Prior to Progress 8.3, there really was no way to "tune" the OpenEdge database to use semaphores more efficiently, other than to enable spinlocks with the -spin database startup parameter which is not relevant to this Article, discussed in
What is the -spin parameter? Starting in Progress 8.3A, multiple semaphore sets were implemented on UNIX platforms, which has always been the default on Windows. With the new implementation, the login and user semaphores are split into different sets, where the login semaphores reside exclusively in the first set while all other sets will contain user semaphores. Since semaphore contention could be attributed to a fair number of performance issues on systems with higher user counts, being able to grant more processes simultaneous access to different resources by letting them access more than just one semaphore pool alleviates this contention.
How to determine what value to use for the -semsets database parameter?It is generally recommendation to have 1 semaphore set for every 20 - 50 users. Example: If a database has a -n of 2500, then the suggested setting for -semsets is 50. As with any performant parameter, more is not better, a point of diminished returns or even performance degradation when the value is set too high. It needs to be tuned to each environment.
The syntax for implementing multiple semsets is as follows:
$ proserve dbname
-semsets 50 -n 2500
If no -semsets is specified then the default value will be set. In OpenEdge 10.1A the default value for semsets is 3, for previous versions check the database.lg file as it differed per version/platform.
Only the Enterprise Database license supports Multiple Semaphore Sets (-semsets).
How to identify Semaphore Contention in an online OpenEdge Database?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 > OtherWhere, 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 databases are using either:
$ ipcs -sa
------ Semaphore Arrays --------
key semid owner perms nsems
0x00000000 851972 root 666 7
0x00000000 884741 root 666 13
0x00000000 917510 root 666 13
Or Semaphore id by user can be viewed through:
$ promon dbname > R&D > debghb > 6 (hidden option) > 16 semaphoresThis will yield three columns:
User (user number)
Id (number of semset)
Num (sem number within set)
User Id Num
0 884741 0
1 917510 0
2 884741 1
3 917510 1
4 884741 2
5 917510 2
6 884741 3
7 917510 3
...
