Date: Tue, 14 Nov 2006 17:11:02 -0600 From: Damian Wiest <dwiest@vailsys.com> To: Robin Becker <robin@reportlab.com> Cc: freebsd-questions@freebsd.org Subject: Re: sysv semaphores Message-ID: <20061114231102.GF20235@dfwdamian.vail> In-Reply-To: <20061114224652.GE20235@dfwdamian.vail> References: <4559DF39.7070506@chamonix.reportlab.co.uk> <20061114224652.GE20235@dfwdamian.vail>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Nov 14, 2006 at 04:46:52PM -0600, Damian Wiest wrote: > On Tue, Nov 14, 2006 at 03:22:33PM +0000, Robin Becker wrote: > > I'm trying to test a python extension (POSH) that uses semaphores. When > > testing I get a run time error that indicates it requires too many > > semaphores. Is it possible to adjust the allowed number of semaphores > > without rebuilding the kernel? > > > > What are the costs of having semaphores ie are they memory/cpu intensive? > > -- > > Robin Becker > > You'll want to use either sysctl(8) to change the settings dynamically, or > use /etc/sysctl.conf to modify the settings permanently. I'm not sure if > there's a benefit to rolling a new kernel versus using sysctl.conf, or if > things even work that way anymore. > > # sysctl -a | grep seminfo > > kern.seminfo.semmni=10 # number of semaphore identifiers > kern.seminfo.semmns=60 # number of semaphores in system > kern.seminfo.semmnu=30 # number of undo structures in system > kern.seminfo.semmsl=60 # max number of semaphores per id > kern.seminfo.semopm=100 # max number of operations per semop call > kern.seminfo.semume=10 # max number of undo entries per process > kern.seminfo.semusz=100 # size in bytes of undo structure > kern.seminfo.semvmx=32767 # semaphore maximum value > kern.seminfo.semaem=16384 # adjust on exit max value > > Those comments are from /usr/include/sys/sem.h > > -Damian Sorry, I forgot to mention a few things. You should become familiar with ipcs(1) as it will allow you to query the current state of SysV IPC facilities. You'll probably find yourself manually deleting semaphores depending on how well that extension cleans up after itself during testing. IIRC, the kernel maintains some in-memory datastructures to keep track of semaphores. I believe increasing the maximum number of semaphores will take up a negligible amount of main memory. If you're interested, the "Design and Implementation of the 4.4 BSD Operating System" (ISBN # 0201549794) has great coverage of this stuff. -Damian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061114231102.GF20235>