On 14/09/2007, Sonam Chauhan <[EMAIL PROTECTED]> wrote: > Hi - > > I was trying to figure out why concurrent JMeter tests (28 instances) > run fine on Windows, but throw out of memory errors on Linux.
You seem to be using different releases of JVM (1.5 / 1.4) which might be relevant. Also maybe Linux is not giving Java enough memory. Does Windows limit memory a process may take? > On both platforms JMeter is run by the 'bin/jmeter' Shell script (on > Windows, it executes under Cygwin). I had modified it's HEAP parameter > downward to: > HEAP="-Xms64m -Xmx256m" > > > Running the tests on Windows, I suddenly realized Windows Task Manager > was showing one of the java.exe process occupying 489 MB. The > implication the Windows JVM did not obey the Xms and Xmx memory limits, > but the one on Linux did. Is this normal? The Xms and Xmx limits apply to the memory the JVM allocates to the Java application, not the limits applied to the JVM by the OS. Though of course higher limits will result in higher OS resource usage. > I plan to increase Xmx to '512m' so that the test runs on Linux. Does > anyone have any comments on these other current parameters in > 'bin/jmeter'? I plan on doubling the PERM parameters and leaving the > others alone. > ================================= > HEAP="-Xms64m -Xmx256m" > NEW="-XX:NewSize=32m -XX:MaxNewSize=128m" > SURVIVOR="-XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=50%" > TENURING="-XX:MaxTenuringThreshold=2" > EVACUATION="-XX:MaxLiveObjectEvacuationRatio=20%" > RMIGC="-Dsun.rmi.dgc.client.gcInterval=600000 > -Dsun.rmi.dgc.server.gcInterval=600000" > PERM="-XX:PermSize=16m -XX:MaxPermSize=64m" > DEBUG="-verbose:gc -XX:+PrintTenuringDistribution" > SERVER="-server" > ARGS="$SERVER $HEAP $NEW $SURVIVOR $TENURING $EVACUATION $RMIGC > $PERM $DEBUG" > > java -server -jar `dirname $0`/ApacheJMeter.jar "$@" > ================================= > > > Kind regards, > Sonam Chauhan > -- > Corporate Express Australia Ltd. > Phone: +61-2-93350725, Email: [EMAIL PROTECTED] > > > PS: > > Here's the output of 'java -version' on both systems. Windows is running > Sun 1.5, but Linux is running 1.4.2. > ----------------------- > WINDOWS: > java version "1.5.0_10" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03) > Java HotSpot(TM) Client VM (build 1.5.0_10-b03, mixed mode) > ----------------------- > > ----------------------- > LINUX: > java version "1.4.2_02" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_02-b03) > Java HotSpot(TM) Client VM (build 1.4.2_02-b03, mixed mode) > ----------------------- > > -----Original Message----- > From: sebb [mailto:[EMAIL PROTECTED] > Sent: Friday, 14 September 2007 12:41 AM > To: JMeter Users List > Subject: Re: running multiple JMeter instance in parallel > > On 13/09/2007, Sonam Chauhan <[EMAIL PROTECTED]> wrote: > > Sebb: > > > > > > > > I've now got to scale the testing up to about 30 concurrent > > > > > > JMeter instances issuing a total of about 30,000 sampler > > > > > > requests in 30 minutes. I'm hoping the same approach should > > > > > > work, by increasing the server memory to 4 GB should help. > > > > > > > > > > How many concurrent threads? > > > > > > > > The number of concurrent threads is difficult to guess, but I'd > > > > estimate a maximum of 1000-1500 concurrently running threads per > > > > JMeter instance for the most intensive tests. > > > > > > > > I tried running the 28 JMeter load test instances on a Linux > VMWare > > > > virtual running on a beefy Quad-CPU ESX server with the following > > > > results: > > > > > > That's about 30-50 threads per JMeter instance. It might be better > to > > > increase the number of threads and reduce the number of instances, > as > > > there will be fewer overheads. > > > > The max. amount of concurrent threads is actually 1500 threads per > > instance. > > Sorry, my bad - I can see (now) that you wrote that originally, but I > overlooked it. > > > Each Jmeter instance runs a separate JMX that load tests a > > component of the overall system. There are some instances with fewer > > concurrent threads. The total number of samplers in all 28 instances > > requested within 20-40 minutes is roundabout 38,000. A Perl script > forks > > and executes all instances, then consolidates the results. > > > > I ran a unified load test (28 instances) on a 3Ghz/3GB RAM Windows XP > > desktop last night. The 28 test instances took up 4 GB of RAM (Windows > > reported a peak total memory usage of 4.6 GB and the OS takes .5 GB) > but > > the tests completed. > > > > I wanted to say I appreciate your inputs -- you answers help a lot of > > people on the list! > > Thanks! > > > Kind regards, > > Sonam Chauhan > > -- > > Corporate Express Australia Ltd. > > Phone: +61-2-93350725, Email: [EMAIL PROTECTED] -----Original > > Message----- > > From: sebb [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, 12 September 2007 8:18 PM > > To: JMeter Users List > > Subject: Re: running multiple JMeter instance in parallel > > > > On 12/09/2007, Sonam Chauhan <[EMAIL PROTECTED]> wrote: > > > Thanks for the advice Sebb! > > > > > > > > The Challenge > > > > > > > > > > I've now got to scale the testing up to about 30 concurrent > JMeter > > > > > > > instances issuing a total of about 30,000 sampler requests in 30 > > > > > minutes. I'm hoping the same approach should work, by increasing > > > > > the server memory to 4 GB should help. > > > > > > > > How many concurrent threads? > > > > > > The number of concurrent threads is difficult to guess, but I'd > > > estimate a maximum of 1000-1500 concurrently running threads per > > > JMeter instance for the most intensive tests. > > > > > > I tried running the 28 JMeter load test instances on a Linux VMWare > > > virtual running on a beefy Quad-CPU ESX server with the following > > > results: > > > > > > > That's about 30-50 threads per JMeter instance. It might be better to > > increase the number of threads and reduce the number of instances, as > > there will be fewer overheads. > > > > > 1) VmWare allocated 2 GB RAM: Java out of memory errors + swap usage > > > --------------------------------------------- > > > java.lang.OutOfMemoryError: unable to create new native thread > > > at java.lang.Thread.start(Native Method) > > > at > > > > org.apache.jmeter.engine.StandardJMeterEngine.run(StandardJMeterEngine > > > .j > > > av > > > a:387) > > > --------------------------------------------- > > > > > > 2) On VmWare but allocated 4 GB RAM: Java out of memory errors -- no > > > more native thread errors. No swap usage detected. > > > ---------------------------------------------- > > > java.lang.OutOfMemoryError > > > Logging Error: Unknown error writing event. > > > ... > > > ---------------------------------------------- > > > > > > 3) Real Hardware > > > I gave up and ran split the test instances into two group - me and a > > > colleague ran 15 concurrent JMeter instances each on 'real' 3GHz P4 > > > machines with 3GB RAM each. At this point, the tests finally ran. I > > > estimate that the overall memory usage (both machines) of the 28 > > > JMeter instances was 3-3.5 GB once the load tests got underway. I > > > suspect the first two failures (on ESX server) may have been caused > by > > > > > the virtualization but I am yet to confirm it. > > > > > > Kind regards, > > > Sonam Chauhan > > > -- > > > Corporate Express Australia Ltd. > > > Phone: +61-2-93350725, Email: [EMAIL PROTECTED] > > > > > > -----Original Message----- > > > From: sebb [mailto:[EMAIL PROTECTED] > > > Sent: Tuesday, 11 September 2007 9:09 PM > > > To: JMeter Users List > > > Subject: Re: running multiple JMeter instance in parallel > > > > > > On 11/09/2007, Sonam Chauhan <[EMAIL PROTECTED]> wrote: > > > > Hi JMeter users - > > > > > > > > > > > > > > > > I wanted your comments on large scale load testing approaches, and > > > > specifically on running multiple JMeter instances running > different > > > > tests. > > > > > > > > > > JMeter is best at running multiple threads all doing the same test. > > > > > > Each thread can use different parameters - these are often used for > > > username/password or similar. > > > > > > However it is possible to use variables in conjunction with > > > conditional controllers to vary the behaviour in each thread. > > > > > > But this can quickly get difficult to set up and manage. > > > > > > > > > > > > > > Approach 1. One Big Plan > > > > > > > > One approach is to have a single humungous test plan with several > > > thread > > > > groups. The disadvantages of this are the test plan becomes big > and > > > > brittle, and the JVM size is susceptible to the 2GB Java memory > > > > limit (on 32 bit systems). > > > > > > > > > > > > > > > > Approach 2. JMeter Distributed Testing > > > > > > > > A second approach is JMeter distributed testing. I've not tried it > > > > because I assume each JMeter instances must run the same test plan > > > > (i.e., the same JMX -- is this right?), plus it seemed > complicated. > > > > > > > > > > Yes, the plan is sent to all the servers. > > > > > > It can be complicated to set up, and by default the client has to > > > handle all the sample responses which can place a huge load on the > > > network connection. > > > There are batch and other modes, but I've not tried these in > earnest. > > > > > > > > > > > Approach 3. External Script runs JMeter Instances in Parallel > > > > > > > > Another approach I've had success with for several years is to run > > > > multiple JMeter instances in parallel. I use a Perl script that > > > > forks separate processes, each running JMeter with a different > > > > testcase. The Perl script waits for all processes to complete, > then > > > > collates the consolidated results by parsing the JMeter XML > > logfiles. > > > > > > > > > > > > > > > > I use this approach to run 15 JMeter concurrent instances on a > > > > server with 2 GB RAM. These issue about 1500 sampler requests in > 10 > > minutes. > > > > The tests all end after 10 minutes and are iterated by rerunning > the > > > > > > Perl script. All this is in non-GUI mode, of course. > > > > > > > > > > > > > > > > To get the 15 tests to run on the one machine, I had to pare down > > > JMeter > > > > memory requirements (see the JVM parameters below). I basically > > > reduced > > > > HEAP memory usage down and downshifted other parameters to match. > > > > > > > > > > > > The Challenge > > > > > > > > I've now got to scale the testing up to about 30 concurrent JMeter > > > > instances issuing a total of about 30,000 sampler requests in 30 > > > > minutes. I'm hoping the same approach should work, by increasing > the > > > > > > server memory to 4 GB should help. > > > > > > How many concurrent threads? > > > > > > > > > > > Any comments on this approach and/or the JVM parameters I'm using > > > below? > > > > > > > > > > See above. > > > > > > > > > > > > > > > Kind regards, > > > > > > > > Sonam Chauhan > > > > > > > > -- > > > > > > > > Corporate Express Australia Ltd. > > > > > > > > Phone: +61-2-93350725, Email: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > Modified JVM parameters set in 'bin/jmeter' > > > > > > > > > > > > > > > > HEAP="-Xms64m -Xmx256m" > > > > > > > > NEW="-XX:NewSize=32m -XX:MaxNewSize=128m" > > > > > > > > SURVIVOR="-XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=50%" > > > > > > > > TENURING="-XX:MaxTenuringThreshold=2" > > > > > > > > EVACUATION="-XX:MaxLiveObjectEvacuationRatio=20%" > > > > > > > > RMIGC="-Dsun.rmi.dgc.client.gcInterval=600000 > > > > -Dsun.rmi.dgc.server.gcInterval=600000" > > > > > > > > PERM="-XX:PermSize=16m -XX:MaxPermSize=64m" > > > > > > > > DEBUG="-verbose:gc -XX:+PrintTenuringDistribution" > > > > > > > > SERVER="-server" > > > > > > > > ARGS="$SERVER $HEAP $NEW $SURVIVOR $TENURING $EVACUATION $RMIGC > > > > $PERM $DEBUG" > > > > > > > > java -server -jar `dirname $0`/ApacheJMeter.jar "$@" > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > 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] > > > > > > --------------------------------------------------------------------- > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
