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 <[email protected]> wrote: > xOn Mon, Mar 28, 2011 at 8:45 PM, sebb <[email protected]> wrote: > >> On 28 March 2011 10:32, Sonam Chauhan <[email protected]> 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 <[email protected]> wrote: >> > >> >> On 28 March 2011 02:57, Sonam Chauhan <[email protected]> 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: [email protected] >> >> For additional commands, e-mail: [email protected] >> >> >> >> >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
