"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 <[email protected]> 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 <[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] > > > > >
