Re: About these IPC parameters

Peter Eisentraut <peter_e@gmx.net> writes:
> We use three shared-memory segments: One is for the spin locks and is of
> negligible size (144 bytes currently). The other two I don't know, but one
> of them seems to be sized about 550kB + -B * BLCKSZ

The shmem sizes depend on both -B and -N, but the dependence on -B is
much stronger.  Obviously there's 8K per -B for the buffer itself,
and there's also some allowance for hashtable entries for the buffer
indexing tables.  The -N number drives the size of the PROC table plus
some hashtables --- but a PROC entry isn't very big.

I believe there's no really fundamental reason why we use three shmem
segments and not just one.  I've toyed with the idea of trying to
combine them, but not done anything about it yet...

> My kernel has the following interesting-looking shared memory settings:

FWIW, HPUX does not have SHMALL --- and since HPUX began life as SysV
I would imagine a lot of other SysV derivatives don't either.  The
relevant parameters here seem to be

SEMA            Enable Sys V Semaphores
SEMAEM          Max Value for Adjust on Exit Semaphores
SEMMAP          Max Number of Semaphore Map Entries
SEMMNI          Number of Semaphore Identifiers
SEMMNS          Max Number of Semaphores
SEMMNU          Number of Semaphore Undo Structures
SEMUME          Semaphore Undo Entries per Process
SEMVMX          Semaphore Maximum Value
SHMEM           Enable Sys V Shared Memory
SHMMAX          Max Shared Mem Segment (bytes)
SHMMNI          Number of Shared Memory Identifiers
SHMSEG          Shared Memory Segments per Process

Other than shooting yourself in the foot by having SEMA or SHMEM be
0 (OFF), it looks like the parameters that could need raising on this
platform would be SEMMAP, SEMMNI, SEMMNS, SHMMAX.

> Is there any noteworthy relevance of some of the other parameters? I see
> FAQ_BSDI talks about SEMUME and SEMMNU.

AFAIK we don't use semaphore undo, so those are red herrings.
        regards, tom lane