Consultor Eletrônico

Status: Verified

GOAL:

How does Progress use semaphores?

GOAL:

What are semaphores?

FACT(s) (Environment):

UNIX
Progress 9.x

FIX:

There is an explanation of semaphores online at

www.progress.com

Progress Database Administration Guide and
Reference, Section 1.4 Operating System Resources


1.4 Operating System Resources

Semaphores
Semaphores are interprocess communications that act as resource counters. The
database engine uses semaphores to synchronize the activities of server and
self-service client processes that are connected to a database. By default, each
database has an array of semaphores, one semaphore for each user or server. Each process
uses its semaphore when it must wait for a shared resource. Semaphores are not
used for single-user sessions. The Semaphore sets (-semsets) Progress broker
startup parameter allows you to change the number of semaphore sets available to
the broker.

You might also need to set some kernel or system parameters to increase the
number of semaphores. For information on setting kernel and system parameters,
see the "Semaphores" section of Chapter 14, "Managing Performance."

14.7.2 Semaphores
On single-processor systems, Progress uses semaphores to synchronize the
activities of server and self-service client processes that are connected to a
database. By default, each database has an array of semaphores, one semaphore for each
user or server. Each process uses its semaphore when it must wait for a shared
resource. Semaphores are not used for single-user sessions or for client
sessions connecting to a remote database on a server system.

Figure 14-12 shows how semaphores control access to shared resources [see online documentation]


Figure 14-12: How a Semaphore Coordinates Concurrent Access

When process 5 needs access to a record, index, or other shared resource already
locked by process 8, process 5 decrements its semaphore. When the process
holding the lock (process 8) releases the resource, it notifies the waiting
process (process 5) by incrementing the semaphore.

Semaphores are grouped into semaphore sets. Each semaphore set has a unique
identifying number called a semid. Within a semaphore set, individual semaphores
are identified by an integer ranging from 0 to one less than the size of the
semaphore set.

The Progress broker preallocates semaphores when you start the database with
PROSERVE. Each process requires one semaphore. The broker uses two additional
semaphores internally. The database engine uses the following formula to
determine the number of semaphores (#SEM) to allocate:


#SEM = Max-possible-users (-n) + Max-possible-servers (-Mn) + 4

The number of semaphores within the semaphore set is determined by the -n and -Mn startup parameter for each database. You need to include any Progress auxiliary 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 plan to utilize additional auxiliary process, we need to add more to the -n values to account for them. Thus the +4 will not be enough on most newer versions of Progress.


Table 14-2 lists the UNIX kernel parameters that control the number and size of
the semaphore sets.


Table 14-2: UNIX Kernel Parameters That Affect Semaphores

Parameter
Description
Recommended Setting

SEMMNI
The maximum number of semaphore identifiers allowed for the system.
One per active multi-user database.

SEMMSL
The maximum number of semaphores allowed per semaphore identifier (semaphore
set).
(Max-local-users-on-any-databases + Max-#servers-on-any-databases + 4)

You need to consider any Progress auxiliary process you wish to start and add that number to the -n count.

If you set this value too low, the database engine might generate e.rror 1093 or
1130.

SEMMNS
Total number of semaphores allowed for the system.
SEMMSL * number of active databases.

SEMMNU
Maximum number of semaphore undo structures allowed for the system.
Same value as SEMMNS. Some systems do not have this value as a tunable.

If you set this value too low, the database engine might generate error 1081.


When you install Progress, you might have to increase the values of these
parameters. If you are running other software that uses semaphores, take into
account the combined requirements. See your system documentation for information
on how to change these parameters.

The amount of kernel memory required for semaphores is relatively small, so
setting the limits higher than your current needs probably will not affect
performance.

The PROMON Shared Resources option (an R&D option) displays the number of
semaphores used. When you start the broker process, a message specifies the
number of semaphores still available. If the number of database users grows
large, the database engine might exceed the maximum number of semaphores
allowed, specified by the SEMMNS parameter. If this happens, you must
Reconfigure the system's kernel to increase the semaphore limit. You can reduce
semaphore use only by lowering the values of the Number of Users (-n) and/or
Maximum Servers (-Mn) startup parameters.

Allocating Semaphores
By default, the database engine uses one semaphore set for all the semaphores
needed by the database. Starting in version 10.1A the default semsets value is three rather than one on startup.
When greater than 1000 users connect to a single
database, there might be high contention for the semaphore set. Using multiple
semaphore sets helps alleviate this contention and improve performance with high
user counts. The broker startup parameter, Semaphore Sets (-semsets), allows you
to change the number of semaphore sets available to the Progress broker.

The broker uses two groups of semaphores, Login and User. The Login semaphore is
used during connection to the database. The system allocates one User semaphore
for every user specified by the Number of Users (-n) startup parameter. User
semaphores are allocated using a round robin mechanism. If you specify the
number of Semaphore Sets, Progress allocates one set for the Login semaphore and
the remaining sets are used for User semaphores.

In this example, the broker uses two semaphore sets, one for the Login semaphore
and one for the ten User semaphores:


proserve <db-name> -semsets 2 -n 10


In this example, the broker uses three semaphore sets, one for the Login
semaphore, one for five of the User semaphores, and one for the remaining five
User semaphores:


proserve <db-name> -semsets 3 -n 10.