Name Amara Arshad

Roll # 013

Inter process communication for oracle solaris 10:

Inter process communication (IPC):

IPC stands for Inter-process Communication This technique allows the processes to
communicate with each another.

In Solaris 10, most of the shared memory, semaphore and message queue parameters have been
removed and the remaining controls moved to Project-based resource controls.

Shared memory, semaphores and message queues are only enabled if the appropriate kernel
modules are loaded. These are automatically loaded if certain IPC functions are called, but they
can also be forced to load via/etc/system forceload commands or root modload commands.

1) Shared Memory:
Solaris 10 only uses the shmmax and shmmni parameters. (Other parameters are set dynamically
within the Solaris 10 IPC model.)

1) Shmmax (max-shm-memory in Solaris 10+):

This is the maximum size of a shared memory segment (i.e the largest value that can be
used by shmget). Its theoretical maximum value is 4294967295 (4GB), but practical
considerations usually limit it to less than this. Solaris 10 sets shmmaxto 1/4 physical
memory by default, vs 512k for previous versions.

2) Shmmin:

This is the smallest possible shared memory segment size. The default is 1 byte; this
parameter should probably not be tuned.

3) Shmmni (max-shm-ids in Solaris 10+):

Maximum number of shared memory identifiers at any given time. This parameter is used
by kernel memory allocation to determine how much size to put aside
forshmid_ds structures. Each of these is 112 bytes and requires an additional 8 bytes for a
 mutex lock. The maximum setting for Solaris 10, the default is 128 and the maximum
is MAXINT.

4) Shmseg:

Maximum number of segments per process. It is usually set toshmmni, but it should
always be less than 65535.

2) Semaphores
Solaris 10 only uses the semmni, semmsl and semopm parameters. Other
parameters are dynamic within the Solaris 10 IPC model.

1) semmap:

This sets the number of entries in the semaphore map. This should never be greater than
semmni. If the number of semaphores per semaphore set used by the application is "n"
then set semmap = ((semmni + n - 1)/n)+1 or more.
Alternatively, we can set semmap to semmni x semmsl. An undersized semmap leads to
"WARNING: rmfree map overflow" errors. The default setting is 10; Solaris 10 increased
the default to 512. The limit is SHRT_MAX.

2) semmni (max-sem-ids in Solaris 10+):

Maximum number of system wide semaphore sets. Each control structure consumes 84
bytes. for Solaris 10, the default setting is 128. The maximum is 65535.

3) semmns:

Maximum number of semaphores in the system. Each structure uses 16 bytes. This
parameter should be set to semmni x semmsl. The default is 60; the maximum is 2GB.

4) semmnu:

Maximum number of undo structures in the system. This should be set to semmni so that
each control structure has an undo structure. The default is 30, the maximum is 2 GB.

5) semmsl (max-sem-nsems in Solaris 10+):

 Maximum number of semaphores per semaphore set. The default is 25, the maximum is
65535.

6) semopm (max-sem-ops in Solaris 10+):

Maximum number of semaphore operations that can be performed in each semop call.
The default in Solaris 2.5.1-9 is 10, the maximum is 2 GB. Solaris 10 increased the
default to 512.

7) semume:

Maximum number of undo structures per process. This should be set to semopm times the
number of processes that will be using semaphores at any one time. The default is 10; the
maximum is 2 GB.

8) semusz: Number of bytes required for semume undo structures. This should not be tuned;
it is set to semume x (1 + sizeof(undo)). The default is 96; the maximum is 2 GB.

9) semvmx:

Maximum value of a semaphore. This should never exceed 32767 (default value)
unless SEM_UNDO is never used. The default is 32767; the maximum is 65535.

10) semaem:

Maximum adjust-on-exit value. This should almost always be left alone. The default is
16384; the maximum is 32767.

3) Message Queues
Solaris 10 only uses the msgmni, msgmnb and msgtql parameters. (Other parameters are
dynamic within the Solaris 10 IPC model.)

1) msgmap: Number of entries in the msg map. The default is 100, the maximum is 2 GB.

2) msgmax: Maximum size of a message. The default is 2048; the maximum is 2 GB.
Shared memory should be considered for moving large messages between processes; it is
much more efficient for large data transfers.
 3) msgmnb (max-msg-qbytes in Solaris 10+):

Maximum number of bytes for the message queue. Te default is 4096; the maximum is 2
GB. The default in Solaris 10 was increased to 65536 and the maximum increased
to ULONG_MAX.

4) msgmni (max-msg-ids in Solaris 10+):

Number of unique message queue identifiers. The default is 50; the maximum is 2 GB.
The default in Solaris 10 has been increased to 128.

5) msgssz: Message segment size. The default is 8; the maximum is 2 GB.

6) msgtql (max-msg-messages in Solaris 10+): Number of message headers. The default is

40; the maximum is 2 GB. Solaris 10 increased the default to 8192 and the maximum
to UINT_MAX

7) msgseg: Number of message segments. The default is 1024; the maximum is 32 KB.

Solaris 10+ IPC Resource Management:

The Solaris 10 IPC resource management framework was designed to overcome several
shortcomings of the older SVR4-based system. Several parameters were converted to be
dynamically resized, the defaults were increased, the names were changed to be more human-
readable, the resource limits were system-wide (permitting potential conflicts) and reboots were
required for even minor changes.

The Solaris 10 system allows changes to be associated with a project and monitored via prctl.

Resource Management For the purposes of IPC resource management, the following are the
important parameters:

1) project.max-shm-ids: Maximum shared memory IDs for a project. Replaces shmmni

2) project.max-sem-ids: Maximum semaphore IDs for a project. Replaces semmni

3) project.max-msg-ids: Maximum message queue IDs for a project. Replaces msgmni

4) project.max-shm-memory: Total amount of shared memory allowed for a project.

Replaces shmmax

5) process.max-sem-nsems: Maximum number of semaphores allowed per semaphore set.

Replaces semmsl

6) process.max-sem-ops: Maximum number of semaphore operations allowed per semop.

Replaces semopm

7) process.max-msg-qbytes: Maximum number of bytes of messages on a message queue.

Replaces msgmnb

8) process.max-msg-messages: Maximum number of messages on a message queue.

Replaces msgtql