3 ms·

Apologies for the confusion. The aim was to demonstrate that against our expectations the typical heaps in JVM landscape are not set that high and ~25% of the a

by ivom2gi 14y ago

Apologies for the confusion. The aim was to demonstrate that against our expectations the typical heaps in JVM landscape are not set that high and ~25% of the apps are doing just fine with less than 256MB of memory allocated. And another aspect we wished to demonstrate was the sheer size of permanent generation on some of the applications. I have yet to face a leak-free app where permgen > 256MB seems justified ...

millerm 14y ago
So, basically your data could just be showing that 25% of your install base have very small codebases. One of my applications, as an example, has 52MB of jar files. That's compressed data. Now, I am not sure how that eventually equates to how much ram is used to load these files (and I know that not every class will be loaded), but unzipping these jars ends up with over 203 megs of data. I have to have a large PermGen. Perhaps the tool you install should be showing the number of classes loaded and the size of the code in general. But, again what's in a jar file can't tell you how many classes will be loaded because many common API such as hibernate and spring generate thousands and thousands of dynamic proxies that end up being stored in memory for the lifetime of that application. The data also doesn't show if the higher heap users tested out running a lower PermGen/Heap and ran out of memory, hence their increased size. I'd rather allocate too much memory though than run out of memory at a peak time and have one of my hospitals deal with downtime because I saved $25 worth of RAM. Anyway, I'll read the followup but I hope it has more info. The key is you have to profile your application, tune it and your done.
tmarthal 14y ago
Have you profiled any Grails applications? It was a 1.x grails system. I no longer work on the codebase, but we were running into permgen space above 256MB, we believed because of the way that the dynamic classes were created/never-destroyed in Groovy.

by ivom2gi 14y ago

millerm 14y ago

So, basically your data could just be showing that 25% of your install base have very small codebases. One of my applications, as an example, has 52MB of jar files. That's compressed data. Now, I am not sure how that eventually equates to how much ram is used to load these files (and I know that not every class will be loaded), but unzipping these jars ends up with over 203 megs of data. I have to have a large PermGen. Perhaps the tool you install should be showing the number of classes loaded and the size of the code in general. But, again what's in a jar file can't tell you how many classes will be loaded because many common API such as hibernate and spring generate thousands and thousands of dynamic proxies that end up being stored in memory for the lifetime of that application. The data also doesn't show if the higher heap users tested out running a lower PermGen/Heap and ran out of memory, hence their increased size. I'd rather allocate too much memory though than run out of memory at a peak time and have one of my hospitals deal with downtime because I saved $25 worth of RAM. Anyway, I'll read the followup but I hope it has more info. The key is you have to profile your application, tune it and your done.

tmarthal 14y ago

Have you profiled any Grails applications? It was a 1.x grails system. I no longer work on the codebase, but we were running into permgen space above 256MB, we believed because of the way that the dynamic classes were created/never-destroyed in Groovy.