Mailing-List: contact jmeter-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "JMeter Users List" <jmeter-user@jakarta.apache.org>
Received-SPF: pass (athena.apache.org: domain of bjkhanz@gmail.com designates
 209.85.198.189 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=Ywg9qfObd1N+GGMMOlZskgUfv3puTziU0ismhNS6FdiVJlrOHwosTB758rr6GTPdVXzM/eltuQTKlTEDrVICEUfEyuCi9njILRPOAm+HqXJqoHL3jbjsU0lrMbDj7VqUBZTg98tH+Lnq2KNSQPhWr1IHyQuc6MCj3LaqZm96T40=
Message-ID: <f46a90190708300314i54a754f8ha00beefb251b3e62@mail.gmail.com>
Date: Thu, 30 Aug 2007 12:14:17 +0200
From: Bj <bjkhanz@gmail.com>
To: "JMeter Users List" <jmeter-user@jakarta.apache.org>
Subject: Re: OutOfMemoryError
In-Reply-To: <46C8052200192A55@front03.ibpmail.net>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_1706_1054986.1188468857021"
References: <12390604.post@talk.nabble.com>
	 <46C8052200192A55@front03.ibpmail.net>

------=_Part_1706_1054986.1188468857021
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Try to monitor your Jmeter in JMX to see heap and non-heap jvm memory usage.
You can use  Jconsole (if you use sun jvm) or missioncontrol (with jrockit
jvm) Jmx client.

With Xmx1536m, I manage to run Jmeter up to 5000 threads on a bi CPU with
4Go ram Linux box.
It also depends of the complexity of your test plan : if you
download embedded resources, what listener you use, ...
Over 150 threads, JMeter is not very efficient.
Do you really need to simulate 5000 simultaneous clients ?
Try to use "Statistical Aggregate report" listener with a long ramp-up
period to determinate what is the best parallelism to use.

Maybe you can use several Jmeter injector servers.
Or you can try httperf (from HP) if your test plan is very simple and if
you need a lot of parallelism.


regards,

-- 
Bj

On 8/29/07, iblavins <iblavins@temenos.com> wrote:
>
> G'day
>
> The 'problem' is that your 250 threads are probably legitimately using the
> 1G of heap you have provided.
>
> But there are several things you should do:
>
> 1. Firstly check that the JVM process is in fact getting 1G of heap space
> -
> just watch the JVM process memory usage. If process is using something
> over
> 1G at the point of failure then you have effectively provided 1G of heap
> space. If its not using something over 1G then review how you call for 1G
> of
> heap space i.e. whether how you set the heap parameters is actually
> working.
>
> 2. I take it for granted that you have 1G of memory plus enough for the
> operating system (presuming Windows) plus some for the other parts of the
> JVM - probably 1.5 to 2G.
>
> 3a. Assuming the above are okay then run JMeter with 50 threads and obtain
> the steady state amount of memory used by the JVM.
>
> 3b. Do the same again with 150 threads.
>
> 3c. Take the difference between the two and divide by the extra threads
> (100
> in this case). This will give you the amount of memory used per thread.
> This
> will give you an indication of how big to make your heap.
>
> 4. In all probability 3c will give you an answer that is too big for your
> machine either because it doesn't have that much memory and/or your Java
> installation is 32 bit and you can only have 2G of heap memory. Your
> options
> then are to go to distributed testing, using enough machines (probably
> around 20) to run all the threads and/or increase the memory on the box
> and
> install a 64 bit version of Java (if it available for your machine).
> Probably you will have to go for distributed testing.
>
> 5. 4. isn't as bad as it sounds because you would need a very strong
> machine
> to run 5,000 threads (assuming a think time of a small number of seconds
> or
> less). Even if you had enough memory on your current machine you probably
> wouldn't have enough CPU to run 5,000 threads. The operating system might
> also need not be able to support 5,000 concurrent threads.
>
>
>
>
>
> Ian Blavins
> Contract Performance Engineer
> Temenos
>
> -----Original Message-----
> From: jada [mailto:jimmy.lam@navy.mil]
> Sent: 29 August 2007 17:23
> To: jmeter-user@jakarta.apache.org
> Subject: OutOfMemoryError
>
>
> Hello,
>
> I have a test plan with Number of Threads = 5000. Each thread will send an
> HTTP request to a JSP which queries data from an Oracle database.
>
> When the #Samples reaches around 250, the JMeter console displays this
> message:
>
> ------------------------------
> java.lang.OutOfMemoryError: unable to create new native thread
>         at java.lang.Thread.start(Native Method)
>         at
> org.apache.jmeter.engine.StandardJMeterEngine.run(
> StandardJMeterEngine.java:
> 400)
>         at java.lang.Thread.run(Unknown Source)
> ------------------------------
>
> The jmeter.bat has been configured with
>
> set HEAP=-Xms1024m -Xmx1024m
> set NEW=-XX:NewSize=256m -XX:MaxNewSize=256m
>
> I'm using JMeter 2.2 and have tried 2.3RC3 with no luck. What could be the
> problem? Memory leak somewhere in JMeter or the Web App? How can you debug
> this?
>
> Please advise.
>
> Jada
> --
> View this message in context:
> http://www.nabble.com/OutOfMemoryError-tf4348833.html#a12390604
> Sent from the JMeter - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
>
>
> This email (and any attachments) contains confidential information, and is
> intended
> only for the named recipient. Distribution or copying of this email by
> anyone
> other than the named recipient is prohibited. If you are not the named or
> intended recipient, please notify TEMENOS or the sender immediately and
> permanently destroy this email (and any attachments) and all copies of it.
> No
> member of TEMENOS Group AG or any of its associated or affiliated
> companies is
> liable for any errors or omissions in the content or transmission of this
> email. Any opinions contained in this email are solely those of the author
> and,
> unless clearly indicated otherwise in writing, are not endorsed by any
> member
> of TEMENOS Group AG or any of its associated and affiliated companies.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>

------=_Part_1706_1054986.1188468857021--