On 14 August 2012 10:51, Milamber <[email protected]> wrote: > > > Le 13/08/2012 18:58, sebb a ecrit : > >> On 13 August 2012 17:07, sebb<[email protected]> wrote: >>> >>> I've made the changes to merge the OnDemand code back into the >>> standard ThreadGroup. >>> >>> This means it's now trivial for users to switch between the different >>> startup types. >>> >>> I hope I've not broken anything ... >> >> Seems to work OK with a simple test plan of a single Java sampler, 10 >> loops. >> Setting the ramp-up to the same as the thread count gives me a max of >> 3 threads concurrently. >> >> This runs out of memory when run without delayed start and 10000 threads. >> The same test starts fine and runs for a while with delayed start. > > > I've run a simple test of 2 Java sampler (with 1s sleep time), 10 loops, > with 120000 threads and ramp-up 6000s with jmeter-trunk (on Linux 64 bits > server with 48 cores, sun jdk 6 64bits) > > === > With delayed start, test works fine. > 2400004 of sampler results > > Max heap size during tests: ~2.6 GB > (jmeter java opts : HEAP="-Xms8g -Xmx8g -XX:+UseConcMarkSweepGC > -Xloggc:/tmp/gclog_`date '+20%y%m%d%H%M%S'`.txt") > > Average number of LWP (Light-weight process): ~500 (~threads inside the > java process via the linux command 'ps') > > === > Without delayed start: OutOfMemoryError: unable to create new native thread. > 45176 of sampler results (test not ended, kill by me after the OOME > notification) > > Max heap size during tests: ~2.3 GB > (jmeter java opts : HEAP="-Xms8g -Xmx8g -XX:+UseConcMarkSweepGC > -Xloggc:/tmp/gclog_`date '+20%y%m%d%H%M%S'`.txt") > > Max number of LWP (Light-weight process): 30396 (~threads inside the java > process) > > === > > Conclusion IMHO: A great behavior for JMeter and tests with a huge number of > threads (users) with small number of individual loops per user, like > webservice's test
Thanks! I'm currently working on delaying the creation of JMeterThread instances. These take quite a bit of memory, and they aren't needed until just before the thread starts. This means moving code from StandardJMeterEngine to ThreadGroup. Quite a lot of changes, but it's looking very promising - many more threads can be started, as memory is then only taken for active threads. I should be able to commit the code later today or tomorrow. > Milamber > > >> It's much quicker to stop the test as well. >> >> I was able to start a test with 50000 threads, but after that memory >> was a problem. >> Also, the test takes quite a long time to start up, presumably because >> of the array of JMeterThread instances. >> >>> There's probably still some tidying up that could be done. >>> >>> For example, StandardJMeterEngine still creates the JMeterThread >>> instances at the start. It might be better to make the thread group >>> class responsible for handling these, so the additional objects are >>> not created until needed. >> >> I think that's what broke my tests with more than about 60000 threads. >> >> As well as deferring creation of these objects,they need to be >> released once the thread has completed. >> >>> BTW, my French is not up to translating the delayed_start property >>> entry - please can someone else fix that so the tests no longer fail? >>> Thanks! > >
