Perl 5.8.6 to 5.8.7 upgrade fails IPC tests

[Louis LeBlanc]

On 06/26/05 04:50 PM, Mikko Tyljrvi sat at the `puter and typed:
> > <SNIP>
> > This certainly does make sense, but I'm not sure I'm actually running
> > short here.  I have SYSVSEM in my kernel (as well as SYSVSHM and
> > SYSVMSG), and the relevant sysctls are:
> >
> > kern.ipc.semmap: 30
> > kern.ipc.semmni: 10
> > kern.ipc.semmns: 60
> > kern.ipc.semmnu: 30
> > kern.ipc.semmsl: 60
> > kern.ipc.semopm: 100
> > kern.ipc.semume: 10
> > kern.ipc.semusz: 92
> > kern.ipc.semvmx: 32767
> > kern.ipc.semaem: 16384
> 
> Ok, looks like the default settings, which are often too low for
> anything that makes heavy use of SYSV IPCs...
> 
> >
> > <root># ipcs -S
> > seminfo:
> >        semmap:     30  (# of entries in semaphore map)
> >        semmni:     10  (# of semaphore identifiers)
> >        semmns:     60  (# of semaphores in system)
> >        semmnu:     30  (# of undo structures in system)
> >        semmsl:     60  (max # of semaphores per id)
> >        semopm:    100  (max # of operations per semop call)
> >        semume:     10  (max # of undo entries per process)
> >        semusz:     92  (size in bytes of undo structure)
> >        semvmx:  32767  (semaphore maximum value)
> >        semaem:  16384  (adjust on exit max value)
> >
> > <root># ipcs -s
> > Semaphores:
> > T     ID     KEY        MODE       OWNER    GROUP
> > s  65536    5432001 --rw-------    pgsql    pgsql
> > s  65537    5432002 --rw-------    pgsql    pgsql
> > s  65538    5432003 --rw-------    pgsql    pgsql
> 
> ... such as databases :-)
> 
> Have a look at /usr/ports/databases/postgresql80-server/pkg-message-server
> for some sample settings.
> 
> > Near as I can tell, this tells me I have at least 60 semaphores
> > systemwide, 60 per id, 3 in use, none of which are being used by root
> > (which is who I am running the test as).  Shouldn't that leave 57 for
> > the perl tests?
> 
> Not necessarily.  The SYSV IPCs is a particularly vicious piece of
> poor engineering.
> 
> Semaphores come in sets containing one or more semaphore.  With your
> settings you can have at most 10 sets, and a total of at most 60
> semaphores, and at most 60 per set, and at most 30... something else.
> Also, at most 30 locks can be released in case a process unexpectedly
> exits.
> 
> Easy, right?
> 
> Looks like you'll have to use "ipcs -sa" to see the "NSEMS" column,
> which should tell you how many semaphores are in use.
> 
> > How many does it need to open?
> 
> No idea.  Read the code or just raise the retarded limits by a lot.
> Or try stopping postgres while running the tests.
> 
>    $.02,
And then some.

You called this one right on the nose.

ipcs -sa showed each of the 3 pgsql processes were using 17 semaphores
(NSEMS column) wich really did cut things down.  The
pkg-message-server file shed some light too.

I first shut down postgres, then ran the test, and everything worked
fine.  Then I added the 3 lines below to /boot/loader.conf, then
rebooted and ran the tests again with postgres still running, and
everything worked fine again.

kern.ipc.semmns=240
kern.ipc.semume=40
kern.ipc.semmnu=120

So, I suspect I have enough semaphores for awhile now:
$ ipcs -S
seminfo:
        semmap:     30  (# of entries in semaphore map)
        semmni:     10  (# of semaphore identifiers)
        semmns:    240  (# of semaphores in system)
        semmnu:    120  (# of undo structures in system)
        semmsl:     60  (max # of semaphores per id)
        semopm:    100  (max # of operations per semop call)
        semume:     40  (max # of undo entries per process)
        semusz:     92  (size in bytes of undo structure)
        semvmx:  32767  (semaphore maximum value)
        semaem:  16384  (adjust on exit max value)


Thanks again.

Lou
-- 
Louis LeBlanc                          FreeBSD-at-keyslapper-DOT-net
Fully Funded Hobbyist,                   KeySlapper Extrordinaire :)
Please send off-list email to:         leblanc at keyslapper d.t net
Key fingerprint = C5E7 4762 F071 CE3B ED51  4FB8 AF85 A2FE 80C8 D9A2

Logg's Rebuttal to Gray's Law:
  `n+1' trivial tasks take twice as long as `n' trivial tasks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20050626/abbcd883/attachment.bin