jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anthony Johnson <ans...@gmail.com>
Subject Re: “cannot create native thread” error and memory usage
Date Mon, 28 Mar 2011 12:52:11 GMT
We had to tackle a non-jmeter 64 bit problem at my work related to
memory.  The CompressedOop feature of the Sun/Oracle JVM is really
nice in getting some of that performance and memory back.

http://wikis.sun.com/display/HotSpotInternals/CompressedOops

Probably worth mentioning in any 64bit tuning guide.

On Mon, Mar 28, 2011 at 8:04 AM, 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). :)
>
>
>> 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