Viewing IPC activity

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.

Semaphore resources

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.

If the sema/s column 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:

• They increased contention between processors -- this reduced scaling and prevented the available CPU power being used effectively.

• They increased activity on the run queues as several processes sleeping on a semaphore could be woken when its state changed -- this increased system overhead.

• They increased the likelihood of context switching -- this also increased system overhead.

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 and message queue resources

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:

• Each process that calls msgget(S) with either of the flags IPC_CREAT or IPC_PRIVATE set obtains an ID for a new message queue.

• The total number of available message headers (MSGTQL) must be less than or equal to 16383. This limits the total number of messages system-wide because each unread message must have a header.

• The total number of segments configured for use (MSGSEG) must be less than or equal to 32768. This limits the total number of messages system-wide because each message consists of at least one segment.

• The size of each message segment (MSGSSZ) is specified in bytes and must be a multiple of 4 in the range 4 to 4096. Each message is allocated enough segments to hold it; any remaining space in the last segment allocated to a message is unused. A small value of MSGSSZ is suitable for systems which will send and receive many small messages. A large value is suitable if messages are fewer and larger. Small segments require more processing overhead by the kernel as it keeps track of them; large segments can be wasteful of memory.

• The total amount of memory reserved for use by message data is controlled by the product of the number of segments and the segment size:
  
  MSGSEG MSGSSZ

  This value must be less than or equal to 128KB (131072 bytes).

• Increase the size of the map used for managing messages (MSGMAP) if a large number of small messages are processed. Typically, you should set the map size to half the number of memory segments configured (MSGSEG). Do not increase MSGMAP to a value greater than that of MSGSEG.

• The amount of message data allowed in an individual queue (MSGMNB) must be less than or equal to 64KB - 4 bytes (that is, less than or equal to 65532 bytes).

• The maximum length of an individual message is limited by the value of MSGMAX. Although the recommended maximum is 8192 bytes (8KB), the kernel can support messages up to 32767 bytes in length. Note, however, that the message size may also be limited by the value of MSGMNB.

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

Parameter	Maximum value
MSGMAP	131072 / MSGSSZ
MSGMAX	32767
MSGMNB	65532
MSGMNI	1024
MSGSEG	131072 / MSGSSZ
MSGTQL	MSGMNB / MSGSSZ

For more information on the kernel parameters that you can use to configure message queues, see ``Message queues'' and ``Message queue parameters''.

Shared memory resources

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''.

SUDS library spin locks and latches

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

Command	Field	Description
[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