Documenting the kernel.sem
sysctl
Programs on our web server machine recently started complaining about
being unable to set up semaphores (well, once we figured out what the
error message meant). This rapidly sent us on an expedition into the
underdocumented mists of the kernel.sem
sysctl, and so I'll write
down what I've learned about what I think is going on.
In the grand style of System V IPC in general, what programs allocate
is not semaphores, but semaphore arrays (officially called 'semaphore
sets'). A semaphore array has one or more actual semaphores (pretty much
always one these days) and a unique semaphore identifier. In ipcs -s
output, these are nsems
(how many semaphores are in the array) and
semid
respectively.
The kernel.sem
sysctl lets you set three different limits related
to this:
- how many semaphore arrays can be allocated (
SEMMNI
, the fourth field). - how many semaphores can be allocated in total (
SEMMNS
, the second field). - how many semaphores can be in a single semaphore array (
SEMMLS
, the first field).
(The third field has to do with the semop(2)
system call.)
The limit you're most likely to run into is how many semaphore arrays can be allocated, which is a pretty low number (128, regardless of how much memory you have). I believe that bumping it up is pretty much completely harmless, especially as all the kernel uses this value for is to limit how many semaphore arrays can be in existence at once.
As a side note that's unlikely to ever be important, there's
an undocumented hard limit of 32768 on SEMMNI
(IPCMNI
, in
include/linux/ipc.h
).
(For more details on all of this, see the proc(5)
and semget(2)
manpages. Unfortunately the proc
manpage doesn't have a pointer to
semget
; if it did, things would be much less confusing.)
|
|