Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> Fantastic Information on Sun Semaphores

Fantastic Information on Sun Semaphores

From: <Cherie_Machler_at_gelco.com>
Date: Wed, 14 Feb 2001 15:14:01 -0800
Message-ID: <F001.002B4A14.20010214141609@fatcity.com>

My sys admin found the following document on a Sun Bulletin Board. It is by far the most comprehensive writeup I've seen on the topic.

File this one away. It'll come in helpful sometime.

Enjoy,

Cherie Machler
Gelco Information Network

INFODOC ID: 2270
SYNOPSIS: Understanding semaphores, seminfo_ semaphore info DETAIL DESCRIPTION: The Solaris 2.X kernel comes configured with defaults for semaphore parameters which may not be large enough for certain applications. Care is warranted in altering them, as these changes will effect any program which makes semaphore system service calls.

This document provides the default and maximum values for the semaphore tunable parameters, and supplies a description of each of them. In most cases, the listed maxima is the largest value which will fit in the data type of the parameter; they are not intended as suggested settings. Specific maxima can not be provided in a general document, as they are dependant upon the hardware resources available on the system being tuned, and on the application(s) making use of them.

Some parameters list more than one value in the 'Max' column. This indicates that the maximum value for the tunable parameter does not match the maximum value which is supported by other elements of the system. In these instances, the first number is the limit imposed by the parameter data type, while the second number is the limit imposed by the parameters usage; where supplied, the usage value must be considered the upper limit for tuning. Unless otherwise noted, setting a parameter to a value larger than the specified usage limit will not return an error, but will result in indeterministic behavior.

Name Default Max Brief Description

------  ------- -------------- -------------------------------------

semmap  10      2147483647      Number of entries in semaphore map

semmni  10      65535           Number of semaphore sets (identifiers)

semmns  60      2147483647      Number of semaphores in the system
                65535 (usage)

semmnu  30      2147483647      Number of "undo" structures in the system

semmsl  25      2147483647      Max number of semaphores, per semaphore id
                65535 (usage)

semopm  10      2147483647      Max number of operations, per semaphore call

semume  10      2147483647      Max number of "undo" entries, per process

semusz  96      *see below*     Size in bytes of "undo" structure

semvmx  32767   2147483647      Semaphore maximum value
                65535 (usage)

semaem  16384   2147483647      Adjust on exit maximum value
                32767 (usage)


Detailed Descriptions


semmap

Defines the size of the semaphore resource map; each block of available, contiguous semaphores requires one entry in this map. This is the pool from which semget(2) acquires semaphore sets.

When a semaphore set is removed (deleted), if the block of semaphores to be freed is adjacent to a block of semaphores already in the resource map, the semaphores in the set being removed are added to the existing map entry; no new map entry is required. If the semaphores in the removed set are not adjacent to those in an existing map entry, then a new map entry is required to track these semaphores; if there are no more map entries available, the system has to discard an entry, 'permanently' losing a block of semaphores
(permanence is relative; a reboot fixes the problem). If this should occur,
a WARNING will be generated, the text of which will be something like "rmallocmap: rmap overflow, lost ...". The end result is that a user could later get ENOSPC errors from semget(2) even though it doesn't look like all the semaphores are allocated.

semmni

Defines the number of semaphore sets (identifiers), system wide. Every semaphore set in the system has a unique indentifier and control structure. The system pre-allocates kernel memory for semmni control structures; each control structure is 84 bytes. If no more identifiers are available, semget(2) returns ENOSPC.

Attempting to set semmni to a value greater than 65535 will result in generation of a WARNING, and the value will be set to 65535.

semmns

Defines the number of semaphores in the system; 16 bytes of kernel memory is pre-allocated for each semaphores. If there is not a large enough block of contiguous semaphores in the resource map (see semmap) to satisfy the request, semget(2) returns ENOSPC.

Fragmentation of the semaphore map will result in ENOSPC errors, even though there may appear to be ample free semaphores. Despite attempts by the system to merge free sets (see semmap), the size of the clusters of free semaphores generally decreases over time. For this reason, semmns frequently must be set higher than the actual number of semaphores required.

semmnu

Defines the number of semaphore undo structures in the system. semusz (see below) bytes of kernel memory are pre-allocated for each undo structure; one undo structure is required for every process for which undo information must be recorded. semop() will return ENOSPC if it is requested to record undo information and there are no undo structures available.

semmsl

Limits the number of semaphores that can be created for a single semaphore id. If semget(2) returns EINVAL, this limit should be increased. This parameter is only used to validate the argument passed to semget(2). Logically, it should be less than or equal to semmns (see above). Setting semmsl too high might allow a few identifiers to hog all the semaphores in the system.

semopm

Limits the number of operations that are allowed in a single semop(2) call. If semop(2) returns E2BIG, this limit should be increased. This parameter is only used to validate the argument passed to semop(2).

semume

Limits the number of undo records that can exist for a process. If semop(2) returns EINVAL, this limit should be increased. In addition to its use in validating arguments to semop(2), this parameter is used to calculate the value of semusz (see below).

semusz

Defines the size of the semaphore undo structure. Any attempt to modify this parameter directly will be ignored; semusz is always calculated based upon the value of semume (see above); semusz = 8 * (semume + 2).

semvmx

Limits the maximum value of a semaphore. Due to the interaction with undo structures and semaem (see below), this tuneable should not be increased beyond its default value of 32767, unless you can guarantee that SEM_UNDO is never and will never be used. It can be safely reduced, but doing so provides no savings.

semaem

Limits the maximum value of an adjust-on-exit undo element. No system resources are allocated based on this value.

Setting Semaphore Parameters


Semaphore parameters are changed by editing the /etc/system file and adding lines of the form:

  set semsys:seminfo_variable = value

where 'variable' is one of the entries from the name column, above. For example, the entry:

  set semsys:seminfo_semmap = 15

would increase the size of the semaphore resource map to 15.

After modifying the /etc/system file, the system must be rebooted in order to implement the new values.

Checking Semaphore Parameters


InterProcess Communication (IPC) parameters can be checked via the sysdef command:

  $ sysdef -i

Toward the bottom of the output, there will a section which should look something like the following:

*
* IPC Semaphores
*

    10 entries in semaphore map (SEMMAP)     10 semaphore identifiers (SEMMNI)
    60 semaphores in system (SEMMNS)
    30 undo structures in system (SEMMNU)     25 max semaphores per id (SEMMSL)
    10 max operations per semop call (SEMOPM)     10 max undo entries per process (SEMUME)  32767 semaphore maximum value (SEMVMX)  16384 adjust on exit max value (SEMAEM)

The values at the left will reflect either the default value, or the value specified in the /etc/system file, if that parameter has been modified.

If the values displayed are all zero, load the semaphore module:

  # modload -p sys/semsys

and run sysdef -i again.

Kernel Memory Limitation


In release 2.5 and higher, the semaphores structures are prevented from using more than 1/4 of all kernel memory; if the specified tuning values would surpass this limit, a WARNING is generated, and the semaphore module will not be loaded.

APPLIES TO: Operating Systems/Solaris/Solaris 2.x, AFO Vertical Team Docs, AFO Vertical Team Docs/Kernel
ATTACHMENTS:

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: 
  INET: Cherie_Machler_at_gelco.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L

(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
Received on Wed Feb 14 2001 - 17:14:01 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US