Also Please refer:

https://communities.bmc.com/communities/docs/DOC-18162

For some guidelines with respect to 1.6 Java/64 bit for MT.
(Page 7- 11)

Regards,
Ravi

-----Original Message-----
From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Andrew C Goodall
Sent: 17 January 2012 23:06
To: arslist@ARSLIST.ORG
Subject: Re: 32bit Vs.64bit JVM performance

That makes sense, thanks.

Regards,
 
Andrew Goodall
Software Engineer 2 | Development Services |  jcpenney . www.jcp.com  

-----Original Message-----
From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Axton
Sent: Tuesday, January 17, 2012 10:04 AM
To: arslist@ARSLIST.ORG
Subject: Re: 32bit Vs.64bit JVM performance

If you are running out of memory with a 32-bit jvm, you need to move to a 
64-bit jvm.  This happens with the midtier when the size of your concurrent 
user base exceeds a certain number.  Moving to 64-bit will not help performance 
in any way by the mere virtue of moving to 64-bit.  64-bit is all about the 
memory.  You can increase performance by increasing the time between GC cycles, 
you will pick up some performance there.  There are also JVM parameters that 
can help with the performance of 64-bit JVM's.

https://wikis.oracle.com/display/HotSpotInternals/CompressedOops

Axton Grams

On Tue, Jan 17, 2012 at 9:35 AM, Andrew C Goodall <ago...@jcpenney.com> wrote:
> **
>
> I'm soliciting feedback regarding experience observed in the field 
> regarding migrating from 32bit JVM to 64bit processes - is it worth it?
>
>
>
> So we'll be upgrading from 7.5 32bit to 7.6.04 64bit (on Windows 
> 2008), our major objective is to drastically improve client performance.
>
>
>
> Due to BMC R&D response, BMC PS is recommending we stay with the 32bit 
> JVMs
> - what are your thoughts?
>
>
>
> I don't mind extra CPU overhead if it means better performance to the 
> client.
>
>
>
> From BMC Remedy AR System Server 7.6 Performance Tuning for Business 
> Service Management page 20:
>
>
>
> Many BMC customers are moving toward 64-bit platforms and running the 
> 64-bit JVM.
>
> Be aware that the 64-bit JVM has performance overhead (see
>
> http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#64bit_performance).
>
> BMC internal performance stress tests demonstrate that the 32-bit JVM 
> outperforms the
>
> 64-bit JVM by at least 45% in terms of CPU utilization. However, if 
> you need the 64-bit
>
> JVM, consider using hybrid mode and parallel GC as recommended by 
> Oracle, that is, -
>
> XX:+UseCompressedOops and -XX:+UseParallelGC. The details and
>
> implications of using hybrid mode and parallel GC are beyond the scope 
> of this
>
> document.
>
>
>
>
>
> Below is BMC R&D response to BMC PS:
>
>
>
> The deployment architect team response was the following:
>
>
>
> on 32-bit JVM, recommendation is to leave GC at default.
>
>
>
> For the same exact JVM args (minus GC) when 32-bit JVM versus 64-bit
>
> JVM, 32-bit will outperform the 64-bit JVM by about 15% (Sun's 
> official number).
>
>
>
> in our load test, when we run the same exact load with tomcat
>
> hosted by 32 versus 64, 32 has about ½ CPU utilization and 25%
>
> less heap usage.
>
>
>
> so, when running 32-bit JVM, leave GC at default (unless a specific
>
> GC model has shown better perf) and very safe to leave the same
>
> exact JVM heap config as 32 bit JVM will use less heap than exact
>
> same when running 64.
>
>
>
> same token, when running 64-bit JVM, if not full 64-bit addressing
>
> is needed, run in hybrid mode (-XX:+UseCompressedOops); min
>
> perf overhead (better than the 15% Sun published.)
>
>
>
>
>
>
>
> Regards,
>
>
>
> Andrew Goodall
>
> Software Engineer 2 | Development Services |  jcpenney . www.jcp.com
> |  972.431.1518
>
>
>
>
> The information transmitted is intended only for the person or entity 
> to which it is addressed and may contain confidential and/or 
> privileged material. If the reader of this message is not the intended 
> recipient, you are hereby notified that your access is unauthorized, 
> and any review, dissemination, distribution or copying of this message 
> including any attachments is strictly prohibited. If you are not the 
> intended recipient, please contact the sender and delete the material 
> from any computer.
> _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 
www.wwrug12.com ARSList: "Where the Answers Are"
The information transmitted is intended only for the person or entity to which 
it is addressed and may contain confidential and/or privileged material.  If 
the reader of this message is not the intended recipient, you are hereby 
notified that your access is unauthorized, and any review, dissemination, 
distribution or copying of this message including any attachments is strictly 
prohibited.  If you are not the intended recipient, please contact the sender 
and delete the material from any computer.

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 
www.wwrug12.com ARSList: "Where the Answers Are"

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"

Reply via email to