You can use the sar -m command (or mpsar -m for SMP) to see how many System V interprocess communication (IPC) message queue and semaphore primitives are issued per second. Note that you can also use the ipcs(ADM) command to report the status of active message queues, shared memory segments, and semaphores.
Semaphores are used to prevent processes from accessing the same resource, usually shared memory, at the same time.
The number of System V semaphores configured for use is controlled by the kernel parameter SEMMNS.
in the output from sar -m
shows that the number of semaphore primitives called
per second is high (for example, greater than 100),
the application may not be using IPC efficiently.
It is not possible to recommend a value here.
What constitutes a high number of semaphore calls depends on
the use to which the application puts them and the processing
power of the system running the application.
Traditionally, System V semaphores were known to be inefficient and to affect the performance of multiprocessor systems adversely. This was because:
If you are an applications programmer, consider using the SUDS library routines which implement the more efficient POSIX.1b semaphores. These are easier to understand than System V semaphores but they do not provide a way to operate on multiple semaphores simultaneously. This feature of System V semaphores, however, is seldom used.
POSIX.1b semaphores are significantly faster to acquire and drop because the test and set is done in user space; the routines do not need to go into kernel mode unless they have to block. They should provide a performance improvement for low contention semaphores where there is a lot of activity. If locks are held for long periods and processes are likely to sleep, do not expect to see an improvement in performance.
The number of POSIX.1b semaphores configured for use is controlled by the kernel parameter SEM_NSEMS_MAX.
Some database management systems may use a sleeper driver to synchronize processes. (This may also be referred to as a post-wait driver.) If this is not enabled, they may revert to using less efficient System V semaphores. See the documentation provided with the database management system for more information.
For more information on the kernel parameters that you can use to configure semaphores, see ``Semaphores'' and ``Semaphore parameters''.
Messages are intended for interprocess communication which involves small quantities of data, usually less than 1KB. Between being sent and being received, the messages are stored on message queues. These queues are implemented as linked lists within the kernel.
Under some circumstances, you may need to increase resources allocated for messages and message queues above the default values defined in the mtune(F) file. Note that the kernel parameters defined in mtune set system-wide limits, not per-process limits.
Follow the guidelines below when changing the kernel parameters that control the configuration of message queues:
This value must be less than or equal to 128KB (131072 bytes).
The following table shows how to calculate the maximum values for these parameters based on the value of MSGSSZ. Note that MSGSSZ must be a multiple of 4 in the range 4 to 4096:
Calculation of maximum value of message parameters
|MSGMAP||131072 / MSGSSZ|
|MSGSEG||131072 / MSGSSZ|
|MSGTQL||MSGMNB / MSGSSZ|
Shared memory is an extremely fast method of interprocess communication. As its name suggests, it operates by allowing processes to share memory segments within their address spaces. Data written by one process is available immediately for reading by another process. To prevent processes trying to access the same memory addresses at the same time, known as a race condition, the processes must be synchronized using a mechanism such as a semaphore.
The maximum number of shared-memory segments available for use is controlled by the value of the kernel parameter SHMMNI. The maximum size in bytes of a segment is determined by the value of the kernel parameter SHMMAX.
For more information on the kernel parameters that you can use to configure shared memory, see ``Shared memory'' and ``Shared memory parameters''.
If your application uses spin locks and latches from the SUDS library to synchronize processes on multiprocessor systems, you can use the -L option to sar(ADM) (or mpsar(ADM) for systems with an SCO SMP License) to view their activity.
A process that has acquired a spin lock forces other processes that are trying to acquire the lock to wait, by spinning, until it releases the lock. Each spinning process repeatedly executes a short section of kernel code, stopping any other process from using the CPU on which it is executing. Spinning processes cannot be context switched. A process that has acquired and locked a latch forces other processes that are trying to acquire the latch to block (sleep) for a specified period or indefinitely until it unlocks the latch. Sleeping processes can be context switched. For a short period of time, it can be more efficient for a process to spin than to sleep as this avoids the system overhead that a context switch would cause.
See the sar(ADM) manual page for more information about latch activity reported by the -L option.
The following table summarizes the commands that can be used to determine if a system is suffering under heavy system call activity:
Viewing system call activity
|[mp]sar -c||scall/s||total number of all system calls per second|
|sread/s||read system calls per second|
|swrit/s||write system calls per second|
|fork/s||fork system calls per second|
|exec/s||exec system calls per second|
|rchar/s||characters transferred by read system calls per second|
|wchar/s||characters transferred by write system calls per second|
|ipcs -a||status of System V IPC facilities|
|[mp]sar -m||msg/s||message queue primitives per second|
|sema/s||semaphore primitives per second|
|[mp]sar -O||%direct||percentage of AIO requests using the POSIX.1b aio functions|