Consultor Eletrônico

Status: Unverified

GOAL:

What is the -semsets parameter for ?

GOAL:

Multiple Semaphore Sets

GOAL:

Semaphores Contention while running a Progress Database

FACT(s) (Environment):

Progress 8.3x

FACT(s) (Environment):

Progress 9.x

CAUSE:

A semaphore can be defined as access to a shared data object for
multiple processes, and they basically give a process a "license" to
lock a resource ex. record, shmem slot, latch, etc. Progress has
traditionally used 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 typically 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"
for the purposes of this article. The number of semaphores within this
set is determined by the -n startup parameter for each database.

Since the single semset has been implemented since the beginning of
Progress time, we have been able to determine one potentially major
caveat to using just one set. Only one process can have access to this
pool at a given time, and that is regardless of whether the process is
just logging into the database, or is performing a normal processing
type operation. Obviously, if multiple processes are queueing for
access to one pool, then this has potential performance bottleneck
written all over it.

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 parameter. What we do in
this case is 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. Now in version 8.3A we have taken a
significant step in the right direction.

Starting in 8.3A we have 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 needed a way to grant more
processes simultaneous access to different resources by letting them
access more than just one semaphore pool, and that is precisely what
we have done here.

NOTE: 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.


The syntax for implementing multiple semsets is as follows:

proserve dbname -semsets 2 -n 10

The 2 in this case is number of semsets while -n is the number of
users. The -n is optional, and can be parsed from a .pf as well. 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.

There have also been another screen added to the Progress monitor,
promon to display the new semaphore statistics. The path is:

promon/R&D/debghb/6/15(semaphores)

This will yield three columns:

User (user number) Id (number of semset) Num (sem number within set)

This new feature should alleviate lots of performance issues caused by
semaphore contention. Another good tool for semaphore contention is
promon/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..

FIX:

To eliminate semaphores contention for client connections with the Progress database use the parameter -semsets