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
output, these are
nsems (how many semaphores are in the array) and
kernel.sem sysctl lets you set three different limits related
- 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
(For more details on all of this, see the
manpages. Unfortunately the
proc manpage doesn't have a pointer to
semget; if it did, things would be much less confusing.)