Semaphore and Shared Memory Configuration for Classic Servers

About Semaphores and Shared Memory

Shared memory and semaphores are limited system resources built into your kernel. All processes share from the pool of resources that are provided by the operating system. When one application claims shared memory or semaphores the pool size is decreased until that application releases the resource.

The first InterBase process claims the shared memory, on systems that use shared memory, and semaphores for all InterBase processes. The more semaphores you claim, the fewer semaphores are available to other applications. These resources are returned when you run gds_drop, use ipcrm to free system resources, or reboot the system.

The parameters defining the use of system resources for InterBase are held in the isc_config file. Use a text editor to view and modify the file. The first attempt by a process to attach to an InterBase database will automatically start the lock manager. Parameters that have been defined by default or redefined will be in effect at that time.

Before editing the isc_config file, you must stop the lock manager. Check for other InterBase users and ensure no one else is using the system before stopping the lock manager. Use gds_drop -a (all) to stop the lock manager. On some systems this will free all held resources. Other systems may return messages stating that resources are still being held. If resources are still being held, you must manually shut down the lock manager. To manually shut down the lock manager, use the UNIX command ipcs to locate held resources. Use ipcrm to release them. Finally, reissue gds_drop -a until there are no further resource in use messages.

The gds_relay process performs event signal delivery. This process runs only when needed. When you stop all InterBase/Firebird processes, you do not need to also stop gds_relay.

InterBase Lock Manager Parameters


Default: 25 or 32. Defines how many semaphores are used by the lock table. Maximum allowed, 65,536.

  • If the default on your system is 25, it is very important that it be increased. See below.
  • The V4 lock manager requires at least 32 semaphores on all UNIX platforms except Digital UNIX, which requires 64. If you increase the number of semaphores, make the quantity a multiple of 32. Make it a multiple of 64 on Digital UNIX.
  • One semaphore is required by the event manager if applications running at your site use Events.
  • If V3 databases are being used on the server, an additional 32+1 semaphores are required.

If V4_LOCK_SEM_COUNT is larger than the UNIX kernel parameter SEMMNS - 17 - x (where x is the number of semaphores used by other software applications) InterBase will fail to allocate the resources it needs and UNIX will return semget errors. If an InterBase application requires more than V4_LOCK_SEM_COUNT semaphores for locking, then InterBase will return the fatal lock manager error - semaphores exhausted.

DG-UX, SCO UNIX and UnixWare have 25 semaphores configured by default. It is very important to increase this at least to 32. All other platforms have 32 semaphores configured by default.

On Solaris, InterBase does not use semaphores to access V4.0 databases. If you access an V3.3 database on a V4.0 server, the Bridge will use semaphores.


Default: 98,304. The size required is based on the number of users and the size and complexity of your database. If you receive a shared memory error, double the setting for V4_LOCK_MEM_SIZE and re-set SHMMAX as needed. Memory requirements are based on the following:

  • 90 bytes for each buffer, relation, database, and concurrent transaction.
  • 36 bytes for each process attached to a database.
  • 388 bytes for the lock manager.

On platforms where the lock table expands dynamically, this parameter does not need to be changed.

On platforms where the lock table is static, you may need to increase the default setting.

If V4_LOCK_MEM_SIZE is greater than the kernel parameter SHMMAX, InterBase will fail to allocate the resources it needs and UNIX will return shmget errors. If an InterBase application requires more than V4_LOCK_MEM_SIZE shared memory for locking then InterBase will return the fatal lock manager error - not enough shared memory.


Default 16. Do not change this entry. This defines the signal number used by InterBase.


Default : 32,768. You do not need to change this entry. If the events table expands dynamically on your platform this is the starting size for the events table. If the table is static, this is the maximum size for the events table. If V4_EVENT_MEM_SIZE is greater than SHMAX, InterBase will fail to allocate the required resources.

The isc_config file also contains ANY_LOCK_MEM_SIZE (98,04), ANY_LOCK_SEM_COUNT (32), ANY_LOCK_SIGNAL (16) and ANY_EVENT_MEM_SIZE (32,768). These parameters are not version specific and are reserved for future releases.

UNIX Kernel configuration parameters

These UNIX parameters may need to be reconfigured with respect to the InterBase configuration. If any of these parameters are changed, you will need to rebuild the UNIX kernel and re-boot your system.

Defines the maximum semaphores in the kernel. It should be at least V4_LOCK_SEM_COUNT + 16 for the InterBase server, plus 1 if InterBase Events are being used. If any other applications running on the computer use semaphores, SEMMNS should be increased to include those requirements.
Defines the maximum number of semaphore undo structures in the kernel. Semaphore undo structures are allocated on a per-process basis, so the system could potentially need one for every simultaneous process running on the computer. The easiest way to accommodate this is to make SEMMNU greater than or equal to NPROC.
Defines the maximum semaphores per cluster. Since InterBase allocates V4_LOCK_SEM_COUNT semaphores in one cluster, SEMMSL should be at least equal to V4_LOCK_SEM_COUNT.
Is the maximum size of a shared memory segment, this should be greater than or equal to V4_LOCK_MEM_SIZE.
Is the maximum number of processes that can be run on the system. This needs to be greater than the number of InterBase processes running as well as other UNIX processes running simultaneously on the system. If you expect more than NPROC number of client processes increase the setting.

The following UNIX parameters also define semaphores. These settings will not typically need to be changed for the installation.

Should be at least 3. InterBase will not use more than 3. The default value in the kernel is sufficient.
Do not need to be any higher than the kernel default.