"maxthr" state

[Daniel Eischen]

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