Date: Tue, 27 Jan 2004 01:45:02 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: Craig Rodrigues <rodrigc@crodrigues.org> Cc: freebsd-threads@freebsd.org Subject: Re: "maxthr" state Message-ID: <Pine.GSO.4.10.10401270136090.23737-100000@pcnet5.pcnet.com> In-Reply-To: <20040127031654.GA40814@crodrigues.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 26 Jan 2004, Craig Rodrigues wrote: > On Fri, Jan 23, 2004 at 03:25:19PM -0800, Julian Elischer wrote: > > > > > > On Fri, 23 Jan 2004, Alex Boisvert wrote: > > > > > > > > Nevermind, I discovered the kernel sysctl > > > "kern.threads.max_threads_per_proc" with default value 150. I bumped > > > the value to 300 and the app runs fine. (We simulate 250 clients with > > > 250 connections or threads, hence the need for a large value...) > > > > yes, the number could be made bigger but we didn't want to make it > > too easy for wildly out-of-control threadded programs to > > kill the system while the threading system is still "young".. > > 150 is a perfectly reasonable number to start with, but I can see it > could be a problem later on when KSE goes "live". > Due to programming languages like Java, there are a lot > of threads-happy coders out there (unfortunately). Remember though that kern.threads.max_threads_per_proc are the number of kernel threads for the process, not the number of userland threads. Threads blocked in userland don't consume a kernel thread. On the other hand, if the threads are IO bound, they will get blocked in the kernel and consume a kernel thread. -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10401270136090.23737-100000>