jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: “cannot create native thread” error and memory usage
Date Wed, 30 Mar 2011 11:25:40 GMT
On 28 March 2011 13:04, Sonam Chauhan <sonamc@gmail.com> wrote:
> xOn Mon, Mar 28, 2011 at 8:45 PM, sebb <sebbaz@gmail.com> wrote:
>
>> On 28 March 2011 10:32, Sonam Chauhan <sonamc@gmail.com> wrote:
>> > 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.
>>
>> Yes, assuming that none of them fail.
>>
>> Does not have to be loop forever - so long as the last thread starts
>> before any others finish, the same will apply.
>>
>
> That is true. Thanks for the clarifications  Sebb.. its good to know i am
> not in lala land (yet). :)

I'd forgotten that JMeter actually creates and starts all the threads
at once; the ramp-up is implemented by having the threads pause
different amounts before initiating sampling.

So as far as initial memory usage goes, it does not depend on rampup
or average thread time etc.

However, samplers take additional dynamic memory (sample results etc);
the maximum for this will depend mainly on the maximum concurrent
thread count, which is what your formula was about.

For consecutive thread groups, each thread group is allowed to
complete before starting the next.

>
>> From what I have been reading recently, 64-bit JVMs aren't faster than
>> 32-bit, and take more memory because of larger pointer sizes.
>> There will of course be some applications that require a 64-bit JVM,
>> but JMeter probably runs better on 32-bit.
>>
>
> Yes, pointers take up twice the space they used to. Makes one wonder if the
>  RAM compressors of yesteryear will make a comeback . :)
>
> We switched a bunch of AIX application servers running from 32 to 64 bit
> JVMs and I definitely saw the increase in average JVM memory usage. The
> increase in baseline (non load) memory usage  was close to double. Increase
> under load  wasn't that great though.
>
> Hmm... my desktop recently also got upgraded to Windows 7, so I'll test out
> JMeter  in 64bit mode there.
>
> Sonam
>
>
>  >
>> > 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
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org


Mime
View raw message