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 <[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] > >
