Perl 5.8.6 to 5.8.7 upgrade fails IPC tests
FreeBSD at keyslapper.net
Mon Jun 27 03:13:26 GMT 2005
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
> 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.
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.
So, I suspect I have enough semaphores for awhile now:
$ ipcs -S
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)
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
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20050626/abbcd883/attachment.bin
More information about the freebsd-questions