DESCRIPTION
Shared memory is an efficient InterProcess Communications (IPC) mechanism.
One process creates a shared memory segment and attaches it to its
address space.
Any processes looking to communicate with this process through the
shared memory segment, then attach the shared memory segment to their
corresponding address spaces as well. Once attached, a process can
read from or write to the segment depending on the permissions specified
while attaching it.
These tunables effectively set the number of unique segments creatable
system wide, since each segment is assigned an identifier by the kernel.
The identifier is simply a reference generated by the kernel such that
any user process can request a particular segment for sharing with a
simple integer, and let the kernel determine which segment
this corresponds to.
If ShmemExtensions is not installed on the
system (or if the system is 32 bit) then
shmmni
alone determines the number of identifiers.
If ShmemExtensions
is installed on a 64 bit system, then the
shmmni_extended
tunable becomes available. Set to the default value of 0, this tunable
is ignored by the system and
shmmni
sets the number of identifiers as before. For systems requiring more
shared memory identifiers than
shmmni
allows, setting the value of
shmmni_extended
to a positive non-zero value makes
shmmni_extended
determine the number of identifiers instead, allowing a greater number
of identifiers in the system.
Strong caution is advised when using the
shmmni_extended
tunable if Memory Windows are also in use. The system
requires a fixed amount of memory based on the
max_mem_window
and either
shmmni
or
shmmni_extended
tunables. If the maximum number of identifiers is 8,192 the amount
of memory required is approximately 1 Mb plus 0.25 Mb for each
memory window allowed on the system. If
shmmni_extended
is in use and the maximum number of identifiers is increased to
32,768 the memory requirement increases to 5Mb plus 1Mb for each
memory window allowed on the system. This memory can not be returned
to the system for other uses and may lead to memory starvation for
user applications or other system needs - causing inordinate paging,
performance degradation or failure to boot the system entirely.
Who is Expected to Change This Tunable?
Anyone.
Restrictions on Changing
Changes to these tunables take effect at the next reboot.
When Should the Value of This Tunable Be Raised?
shmmni
should be raised if users of System V shared memory are receiving the
ENOSPC
error message on
shmget()
calls.
What Are the Side Effects of Raising the Value?
Kernel memory usage will be slightly increased, as the data structures
used to track the segments are preallocated based on this tunable.
When Should the Value of This Tunable Be Lowered?
If kernel memory is at a premium, or it is known that few segments
will be needed, a slight savings can be gained from decreasing
this tunable, and thus decreasing the data structure memory
usage associated with it.
If System V shared memory is not to be used at all, simply set the
shmem
tunable to
off
instead.
What Are the Side Effects of Lowering the Value?
Kernel memory usage will be slightly reduced.
What Other Tunable Values Should Be Changed at the Same Time?
shmmax
and
shmseg
should be considered.
shmseg
should be changed in the same manner as
shmmni,
since lowering the total number of segments but raising the number
available per process only makes sense if you want a few processes
taking all the segments.
shmmax
is more complex and any changes to it really depend on the
effect desired.
Refer to the
shmmax(5)
manpage for more information before changing this tunable.
Printable version
