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
