Java Performance Tuning

Java(TM) - see bottom of page

|home |services |training |newsletter |tuning tips |tool reports |articles |resources |about us |site map |contact us |
Tools: | GC log analysers| Multi-tenancy tools| Books| SizeOf| Thread analysers|

Our valued sponsors who help make this site possible
JProfiler: Get rid of your performance problems and memory leaks! 

News June 2016

JProfiler
Get rid of your performance problems and memory leaks!


Java Performance Training Courses
COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs

Java Performance Tuning, 2nd ed
The classic and most comprehensive book on tuning Java

Java Performance Tuning Newsletter
Your source of Java performance news. Subscribe now!
Enter email:



JProfiler
Get rid of your performance problems and memory leaks!


Back to newsletter 187 contents

There are general guidelines for the most efficient heap sizes. Firstly, for basic scaling, redundancy and failover capability, the recommendation is to have two or three copies of a JVM instance (three gives you as much as you need, two may be enough). Beyond that, you are better off vertically scaling those three instances (vertical scaling means increase the memory, CPU and I/O for those instances rather than add more JVMs). That's because a JVM has a base cost just to run it, so you gain efficiency by increasing the use of an existing JVM. Of course there may be isolation reasons why you want to run other JVMs, but you need to be aware that you're making a tradeoff, of greater isolation for less efficiency.

A note from this newsletter's sponsor

New Relic - Try New Relic today and get your free Data Nerd shirt!
Free SaaS APMto monitor, troubleshoot, and tune apps
running on Websphere, Weblogic, Tomcat, Jetty, JBoss, Solr, Resin

But there is a higher efficiency limit for JVMs at the per NUMA RAM (including any non-heap memory needs that need to run on that NUMA node). For a typical system the RAM is evenly distributed and the NUMA node corresponds to the socket (ie each multi-core chip, not each core), so if you don't know the hardware architecture for your particular system you can divide total RAM by the number of sockets and that gives you the efficient memory limit for your JVM (of course you are better off finding the exact architecture and using that data). At that point it depends very much on your application whether increasing JVM heap further is more efficient or adding another JVM is.

There are other considerations too, under 4GB heaps are a little more efficient, and the 32GB-64GB heap range has some peculiarities (related to pointer addressing of objects) that make under 32GB heaps more efficient, so you want to stay below 32GB if you will be straying into that range, especially up to around 48GB. Above 64GB there are no differences in efficiency up to the NUMA node memory (but remember that NUMA node limit relates to the process memory which will be larger than the heap if it reaches maximum usage).

So like with most things in performance, you have tradeoffs that need making but at least now you're informed about those tradeoffs. Target having two JVM instances, (three if you need more scale or redundancy), grow those instances up to the NUMA-node size but preferentially try to stay below either 4GB or 32GB max heaps; above NUMA-node RAM you need to test whether a bigger heap single JVM or per-NUMA-node memory restricted JVMs are more efficient. And of course replicate the whole thing in another datacentre if you need disaster recovery or regional capabilities.

Now on to our usual links to tools, articles, news, talks and as ever, all the extracted tips from all of this month's referenced articles.

News

Java performance tuning related news.

Tools

Java performance tuning related tools.

A note from this newsletter's sponsor

Site24x7.com : Deep dive Application Performance Monitoring
Fix performance issues with Java, .NET and Ruby platforms
Monitor app instance at $12/Month. 30-day free trial. Sign Up!

Articles

Jack Shirazi


Back to newsletter 187 contents


Last Updated: 2017-11-28
Copyright © 2000-2017 Fasterj.com. All Rights Reserved.
All trademarks and registered trademarks appearing on JavaPerformanceTuning.com are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. JavaPerformanceTuning.com is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
URL: http://www.JavaPerformanceTuning.com/news/news187.shtml
RSS Feed: http://www.JavaPerformanceTuning.com/newsletters.rss
Trouble with this page? Please contact us