"maxthr" state
Daniel Eischen
eischen at vigrid.com
Tue Jan 27 06:21:46 PST 2004
On Tue, 27 Jan 2004, Julian Elischer wrote:
>
> On Tue, 27 Jan 2004, Daniel Eischen wrote:
>
> > 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.
>
> We are limitted by hardware to 8191 kernel threads on x86
> but that could be a LOT of user threads..
Using libkse, you are limited to 8191 KSEs, not threads.
You can have as many threads for which you have the (other)
resources :)
>
> Hmm how many 64k stacks can you fit in 2GB?
> hmmmm 2^16 into 2^31... well that limits us to 32k threads :-)
--
Dan Eischen
More information about the freebsd-threads
mailing list