Progress
Database Administration
Guide and Reference
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 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.
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:
Table 14–2 lists the UNIX kernel parameters that control the number and size of the semaphore sets.
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. 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:
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:
Copyright © 2004 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095 |