First post in the series analyzed the foundation – on what OS the JVM is run, whether it is a 32 or 64-bit infrastructure and what JVM vendor and version were used. Second post focused on the different application servers used. The one you are reading now sheds some light upon the heap sizes used by Java applications.
For the task at hand we dug into the 1,024 environments we had gathered statistics from. 662 out of those had overridden the default maximum heap size by setting the -Xmx parameter. Also, 414 had felt that the permanent generation is not properly sized and had specified -XX:MaxPermSize by themselves.
First lets take a look at the heap sizes. The data when sampled and summarized took the following form:
When you are interpreting the data then – the nine in the 64MB section has to be read that “There were nine environments in the sample with 32MB < maximum allowed heap size <= 64MB.”
But what makes this graph interesting are the outliers. Or, more specifically, the environments with either too large or too small heaps as the results do not actually correspond well to our initial assumptions that 75% of the environments are using between 0.5 and 4GB of heap size. Our guess was close near the reality – 70% of the environments are indeed in this range. But the rest was surprising. Only 4% ran on bigger heap sizes with the biggest heap in our sample being set to 42G.
And the surprise lies within the remaining 26% of the JVMs running with less than 512MB heaps. As a matter of fact, 95% of them are running on 256MB and less. Our initial guess was that those have to be the non – Java EE applications. But the results are not verifying the guess – instead of -client switches and libraries indicating desktop applications we faced a mixture of everything. Even with some Weblogic instances running with 256MB. If you can hint us how are you able to run your Java EE apps on such small heaps, we are all eager to listen.
Second data set in our hands was the permgen. We summarized the 414 environments containing this information:
Again, when interpreting the data looking at the eight samples in 2,048MB column – we had eight environments running with -XX:MaxPermSize larger than 1,024MB and smaller than or equal to 2,048MB.
Some surprises in this diagram as well. First – why do 160 people think that exactly 256MB is the best possible size for the permgen? This constitutes roughly 40% of the environments. And those two who think 258MB is better – are you just bad at calculating the powers of two or have you done some real fine-tuning? And the extremes are also interesting – if you can describe me the applications which are ok with less than a MB of permgen or which would require 6GB of it, I would again be all ears.
While interpreting the data we also got some confirmation to our assumptions that people are solving java.lang.OutOfMemoryError: PermGen space errors via tossing more RAM towards the problem. It just cannot be that 25% of the environments need 512MB or more in the permgen for anything else but covering up permgen leaks.
How Does It Work?
- Download Plumbr
- Attach Plumbr to your application
- Start discovering memory leaks!
(or play with included leaking demo app)
It takes only 5 minutes. Try now!
Enter your e-mail to receive your copy of Plumbr. No credit card details required!-->
Error descriptionWhy our users like us I found Plumbr very easy to set up and get running, which frankly is a great feature. Too often i find new tools to try out that are a hassle to get up and running with. Michael Grove
Clark & Parsia