jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sonam Chauhan <son...@gmail.com>
Subject Re: “cannot create native thread” error and memory usage
Date Mon, 28 Mar 2011 09:32:06 GMT
Oops. you're right Sebb. My formula only works for 1 iteration.. I somehow
managed to edit that out.

If 'loop forever' is set, is it correct to say the number of active threads
= number of threads in thread group. So in your case, that means the JVM
would have 2000 threads active at once,  each thread doing about 3.25
iteration/second, leading to your observed 6500 samples per second
transaction rate?

For a 32bit JVM (which I assume you're using), the stack size per thread is
320 KB (Sun JVM). So your memory usage would be around 2000 * 320 KB + JVM
overhead + minimal heap usage = Approx. 800-850 MB. Is that what you're
seeing?

On a 64 bit JVM, the stack size per thread is 1 MB (Sun JVM). In that case,
your memory usage would cross 2 GB.

Sorry for the rambling... and hope you humor me :D



On Mon, Mar 28, 2011 at 1:59 PM, sebb <sebbaz@gmail.com> wrote:

> On 28 March 2011 02:57, Sonam Chauhan <sonamc@gmail.com> wrote:
> > Hello JMeter users: Just wanted some feedback on a formula for max.
> active
> > threads and some thoughts on errors when running tests with lots of
> threads.
> >
> >
> >
> > Someone recently asked a question about JMeter running out of memory when
> > creating new threads (the “cannot create native thread” error).
> >
> >
> >
> > I came up with this formula for maximum active threads in a thread group
> > with a simple ramp
> >
> >
> >
> > *maximum active threads* = average thread lifetime * total threads/ramp
> > period
> >
> >
> > Does this look right? The way I understand the formula is it finds the
> total
> > threads created by the time the first threads start terminating. Since
> > threads now terminate at the same rate they are being added by the ramp,
> > this is a steady-state figure - the “high water mark” of active threads.
> >
>
> If some threads last longer than others, the maximum may be more.
>
> >
> > As for memory usage, each thread uses heap memory and stack memory. Total
> > heap memory usage limits are defined in the JMeter run script by the
> ‘Xms’
> > (min.) and ‘Xmx’ (max.) flags. Stack memory usage is a fixed memory
> > allocation per thread -- it can be changed by the ‘Xss’ parameter (but
> its
> > best left alone in my experience)
> >
> >
> >
> > A 32-bit JVM running on  a 32-bit OS can occupy 2 GB of RAM at most. As
> some
> > RAM is taken up by the JVM runtime itself, a JMeter instance can really
> > access only 1.5 -1.7 GB of RAM – the sum of both the heap and stack usage
> > fit into this.  So we do need to be careful about allocating too much
> heap.
> > Lets assume *Xms* is set to *1.5 GB *and the test has a high water mark
> of
> > 500 active threads. The JVM will  probably run out of memory creating
> > threads… even though there could be plenty of heap left unused, 500
> threads
> > require about 180 MB of stack (for a 32 bit JVM), and this will cause the
> >  test to  probably generate a “cannot create native thread” error at some
> > point.
>
> The maximum number of thread depends very much on the test plan.
>
> I just created a test with 2000 threads, rampup 200, loop forever.
>
> Currently running at over 6500 samples per second.
>
> This is on WinXP with 2GB memory, Intel Core 2 1.67GZ with Eclipse and
> various other applications running.
>
> But the test only contains a single Java Request sampler and a Summary
> Listener.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message