Re: Available memory and limit on thread creation

From: Joseph Dionne (jdionne_at_hotmail.com)
Date: 07/02/04 

Date: Fri, 02 Jul 2004 19:48:11 GMT

Roedy Green wrote:
> On Thu, 01 Jul 2004 21:10:16 GMT, Joseph Dionne <jdionne@hotmail.com>
> wrote or quoted :
>
>
>>d the largest number of threads I can launch is 1015
>
>
> that is suspiciously near a magic number 1024. It is also a rather
> huge number of threads for a computer with a single CPU.
>

I think you are right. Using the "-server" option reduces the number of
threads by 3 to 1012, so that option must also spin off some threads.

Yes, one might concider 1024 threads a lot of threads, but in my
application, a financial transaction front-end, most of the threads will
be blocking on sockets, so the impact on the CPU is low, however RAM is
impacted greatly.

The target production servers are much larger than my test system.
Unfortunately, they have not be purchased yet, cause I need to tell the
customer how many to purchase.

> You might do an experiment to see what happens when you spin off some
> threads from C in JNI.
>

Yes, my next approach is to put my c/pthreads model into JNI, where I
have more control of memory usage. My approach will be to roll my own
ServerSocketChannel, or something that approaches its functionality,
using native methods for my client socket threads doing socket IO.

> You might do an experiment to see how many threads you can spin off in
> an absolutely trivial program.
>

My test application is very trivial, spinning of threads that just sleep.

> My gut reaction is that this is a reasonable upper bound for a JVM or
> OS to impose.
>

I am checking into all the tunable parameters for Linux, and any help on
sites that list them would be appreciated. I dont believe the limit is
OS related, but within the VM of Java.

> You might consider some sort of thread pooling where you have a FIFO
> queue of work packets to be done, and say 5 real threads feeding off
> it, and then putting incomplete work back on the tail of the queue.
>

What I am tring to create is a thread pool that will service clients
accepted by the ServerSocketChannel. The traffic will be high volume,
low connection times, averaging about 2 to 4 seconds. The application
will be running in a server farm, and so, the fewer threads it can
launch means more servers in the farm. One approach I am looking into
is using Virtual IPs, and start several VM on one box, adding the
Virtual IPs to the router hunt table. Since I can run several VMs, all
of which are limited to 1015 threads on my development system, this
might be the solution.

> This means you have to maintain state yourself. It will almost
> certainly be far more ram-efficient.
>
> The work packets must decide co-operatively when they have done enough
> work for a slice by calling a have-a-conscience method at reasonable
> intervals. You can make the work packet itself responsible for saving
> and restoring state, rather than saving and restoring everything the
> way the system does for a full thread.
>
> I wrote a co-operative thread scheme for Windows 3.1 back before
> Windows had threads. It was a lot simpler than I thought it would be.
> It required some assembler, but not as much as you might think.
> I think what you would do here would not be so general. Chances are
> there is great regularity in what all those threads of yours are
> doing, e.g. spidering a website.
>

Thanks for your help, Roedy.

Quantcast