Kbase 18063: How to and Why Use Multiple Semaphore Sets (-semsets option)?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
5/31/2011 |
|
Status: Verified
GOAL:
How to and Why Use Multiple Semaphore Sets (-semsets option)?
GOAL:
What is the -semsets parameter?
GOAL:
Why use multiple Semaphore Sets?
GOAL:
What is the recommended algorithm to identify how many semsets are needed for a specific database?
GOAL:
What should my semsets database parameter be set to?
GOAL:
How do I identify what -semsets should be set to for a database?
GOAL:
How to identify Semaphore Contention while running a Progress Database?
FACT(s) (Environment):
UNIX
Progress/OpenEdge Product Family
FIX:
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 -n and -Mn startup parameter for each database. You need to include any Progress auxillary process in the -n count in addition to the license 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 account for them.
How to and Why Use Multiple Semaphore Sets (-semsets option):
Since the 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 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, and this access is shared by both login and user processes. At this point we have a sort of "double contention" going on, and a symptom of being low on kernel semaphores is a "warning: only x available wait semaphores" in the beginning of the database .lg file.
Until now, only the latter problem could be addressed by tuning the kernel to make more semaphores available. There really was no way to "tune" Progress to use semaphores more efficiently, other than -spin which is not relevant to this article.
Starting in 8.3A, we implemented multiple semaphore sets on UNIX platforms, as it has always been the default on NT. With the new implementation we split the login and user semaphores into different sets. The login semaphores will 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, we are able to grant more processes simultaneous access to different resources by letting them access more than just one semaphore pool.
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. You need to tune this setting as you may get to a point of diminished returns or even begin to get a performance degradation.
How to identify Semaphore Contention while running a Progress Database:
A good tool to determine if semaphore contention could be a problem on your system is sar -u. If %sys gets higher than 25%, then you may have a semaphore contention problem marked by performance degradation as more users are added.
you may also determine if semaphore contention from the promon R&D screen.
Command Syntax:
promon dbname
R&D
Activity. Displays
Other
The waits on semaphore field will tell you if semaphore is the resource users are waiting on. Optimum numbers for this option will vary from system to system.
The syntax for implementing multiple semsets is as follows:
proserve dbname -semsets 2 -n 100
The 2 in this case is number of semsets while -n is the number of users. The -n is optional, and can also be parsed from a .pf. If no -n value is supplied either from the command line or .pf then it will default to 20. If no -semsets is specified then we will use one set by default.
NOTE: Only the Enterprise Database license supports Multiple Semaphore Sets (-semsets). As of 10.1A the default value for semsets is 3
.