jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Speteanu <asp.ad...@gmail.com>
Subject Re: “cannot create native thread” error and memory usage
Date Mon, 28 Mar 2011 21:46:34 GMT
"Cannot creative native thread" is also related to system software
limitations on desktop distributions (that can usually be tweaked). On
windows 7 however, java runs nicely... I also got some pretty stable results
at 4500 threads with some basic tests just by running jmeter without any JVM
parameters - on the win7 station / 4Gb Ram / quad core, but I wouldn't
recommend more than 250 threads / CPU core when running more complex test
setups.

On Mon, Mar 28, 2011 at 8:24 PM, Deepak Shetty <shettyd@gmail.com> wrote:

> In my experience the maximum number of threads JMeter (or a java
> process)can
> run becomes academic because the response time starts deviating from the
> actual response time(as measured from a different machine for the same
> test)
> a lot earlier (test dependent) - though of course the tuning information is
> always useful.
>
> On Sun, Mar 27, 2011 at 7: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