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 |

Our valued sponsors who help make this site possible
New Relic: Try free w/ production profiling and get a free shirt! 

ManageEngine's Site24x7: End-to-End analysis on Java EE web transactions. Sign up for FREE! 

AppDynamics: Get complete browser to backend visibility. Monitor Now! 

News March 2012

Chart Java Jitter with jHiccup
Monitor and identify pauses in your Java apps. Download now

Why is my application so slow?
Learn 3 ways to detect Java Application Performance Trends

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

See Your Message Here
You could have your tool advertised here, to be seen by thousands of potential customers

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:


New Relic
New Relic: Try free w/ production profiling and get a free shirt!

ManageEngine
ManageEngine's Site24x7: End-to-End analysis on Java EE web transactions. Sign up for FREE!

AppDynamics
AppDynamics: Get complete browser to backend visibility. Monitor Now!


Chart Java Jitter with jHiccup
Monitor and identify pauses in your Java apps. Download now

Why is my application so slow?
Learn 3 ways to detect Java Application Performance Trends

JProfiler
Get rid of your performance problems and memory leaks!


Back to newsletter 136 contents

A long time ago, the first recommendation for initial heap size setting was that ms (starting/initial heap size) should be small, e.g. 4MB, and the mx (maximum heap size) should be big enough to avoid an out-of-memory error. This was intended to allow the heap to naturally grow to whatever it needed, then stabilize at some optimal value. Then after observing typical heap activities people started saying there was no point in having an ms different from mx, you should work out what you need and just set both to be the same, that way your application avoided any overhead in growing the heap to what it would need eventually anyway.

A note from this newsletter's sponsor

New Relic RPM - The Revolution in Java Performance Management is Here!
Affordable SaaS APM tool to monitor, troubleshoot, and tune apps
running on Websphere, Weblogic, Tomcat, Jetty, JBoss, Solr, Resin

Then came more sophisticated GC algorithms and a new suggestion, that ms should be just above the steady-state working memory requirement of the heap, while mx should be (as always) big enough to avoid the out-of-memory error that may otherwise be caused from memory requirements occasionally spiking (a rule of thumb mentioned was to start with ms at half mx, then see where your steady-state was). Some people clung to the "ms should be the same as mx" point of view regardless, saying the heap would stabilize within that anyway. Then we got ergonomic garbage collection algorithms which could vary the maximum heap size dynamically according to it's internal heuristics, and we were told that we shouldn't set ms to mx because this defeated the ergonomics.

The situation right now is that we have a proliferation of different garbage collectors and it's not at all clear whether there is any general recommendation for initial heap size compared to maximum heap size. I'm not certain myself any more. So I thought the best thing I could do is ask you - seeing as you include a majority of the very top Java performance people in the world. So, if you have any idea whether there is a current good recommendation for initial heap size, I'd love to hear it and why. Of course I'll report back next month as to whether there is any kind of consensus or interesting comments.

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

A note from this newsletter's sponsor

Free Java Performance Tool - From AppDynamics
Fight fires in production with less than 2% overhead.
Gain complete visibility into your java app. Free Download!

News

Java performance tuning related news.

Tools

Java performance tuning related tools.

A note from this newsletter's sponsor

ManageEngine: Application Performance Management for Java EE Apps.
Monitor App Servers: JBoss, WebSphere, WebLogic, JVMs and JMX Apps.
*** Monitor up to 25 App Servers, Databases & Servers at $795/Yr***.

Articles

Jack Shirazi


Back to newsletter 136 contents


Last Updated: 2014-04-01
Copyright © 2000-2014 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/news136.shtml
RSS Feed: http://www.JavaPerformanceTuning.com/newsletters.rss
Trouble with this page? Please contact us