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"
