5 ms·

Most popular JVM memory configurations

57 points by ivom2gi 14y ago

BonoboBoner 14y ago
said no one ever?
millerm 14y ago
Umm. I trying to figure out how that title comes from what I just read in that article. The article shows a couple graphs comparing the max heap size and the max PermGen size of ~1000 different installations of java application servers. So? How can you state that java doesn't need that much memory after all? After all what? I know we've run out of PermGen with the JVM set to anything less than 192mb. We've got a pretty large app that (unfortunately) depends on a load of third party libraries. Too many libraries for my taste but that isn't my call. So, we must have this set or the server won't even start. All applications are different and have different memory requirements. Too low of a setting and you are constantly thrashing or running out of memory. Too large and you have huge garbage collection times. It has to be tuned. Now, I've heard (as I haven't really looked into it yet) that the JVM in the JDK 8 distribution has gotten rid of PermGen setting. So, I'm curious to know what 'they' are doing now. Is the G1 garbage collector the new default in JDK 8? Does that not have the PermGen or is this something different? Anyway, I don't know what this post is about yet. They probably should have just finished the thing instead of saying: "If you managed to get this far, then you are most likely interested to hear about our forthcoming posts. Stay tuned by subscribing to our Twitter feed." It was worthless.
- tiemand 14y ago
  I concur! Claiming that Java is not "as memory intensive as thought" means to me that they compared the memory usage profile of java applications with similar applications developed in other languages.
- 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.
- millerm 14y ago
  Replying to myself as I see the title has changed. That makes more sense. Now my comment seems out of context. I had no idea you could change the title of a submission, especially after people commented on it. That's actually scary.
bjoernbu 14y ago
The HN headline is somewhat misleading. It is different from the original article and I was expecting some neat techniques to overcome the typical memory issues: Everything is an object, generics need wrapper classes, padding everywhere. Those make HashMap<Integer>, ArrayList<Integer> or even "two dimensional arrays" a bad joke compared to C(++) equivalents. Projects like Lucene have to rewrite standard library eqiuvalents for specific cases since otherwise so much performance would be lost. Examinating app server -Xmx settings is more handwaving than anything. Especially people that refrain from doing certain things in java due to memory issues, have a completely misleading influence on such a metric.
_pmf_ 14y ago
It would also not hurt to mention the topic of virtual memory vs. "memory usage issue" here.
sil3ntmac 14y ago
Sorry for my naivety, but when does Java use the stack? Only for primitive operations?
- pkolaczk 14y ago
  If you turn Escape Analysis on, it allocates objects not escaping the local method scope on the stack.
philippelh 14y ago
Funny, isn't it? "...whether it is a 32 or 62-bit infrastructure..." and a bit later... "And those two who think 258MB is better – are you just bad at calculating the powers of two..."
- priitp 14y ago
  Well spotted :)
- ivom2gi 14y ago
  Congrats! You were the first one to spot the easter egg we planted, if you contact us referring to your original comment you can have the Plumbr for free for one year.
martinced 14y ago
PermGen, as if all the JVMs out there were Sun/Oracle or the OpenJDK ones ; )
- pjmlp 14y ago
  I still don't understand how developers fail to be aware of the amount of JVMs and even native compilers available for Java out in the wild.
cagenut 14y ago
I have the opposite problem, I can't get java to use "enough" memory. Every time we double it in production that leads to another few weeks of re-jiggering jvm flags and ratios and grepping&graphing the garbage collection log or staring at visualgc for days. We're thinking of giving up on scaling above 16gb/jvm and going to something crazy like 16x2gb jvms. Treat them like the worlds biggest mongrel and let the loadbalancer sort it out.
- ivom2gi 14y ago
  That is indeed our experience as well. Going beyond 8-12GB of heap starts to produce all kind of weird side effects. So our best recommendation is to scale vertically on the heap size ...
- theatrus2 14y ago
  Note that there is a cliff at about 20GB with +CompressedOoops, as the larger heap makes object reference compression impossible, so references return to a full machine word (8 bytes), which depending on your workload and code, can be significant.
- dcminter 14y ago
  It does irritate me that the Sun JVMs do not offer any flag to specify the heap size along the lines of "limited only by the environment" rather than obliging an upper limit to be specified.
- pdog 14y ago
  Honestly, if you really need your JVM to scale above 16 GBs of heap memory, you should go for something like the Zing JVM[1] from Azul Systems. However, the standard JVMs should suffice for 99% of workloads. [1]: http://www.azulsystems.com/products/zing/virtual-machine http://www.azulsystems.com/products/zing/virtual-machine
  - aut0mat0n1c 14y ago
    Huh.. thanks for this. Never heard of zing, looks worth a test drive.
deleted 14y ago
[deleted]
cinbun8 14y ago
The post compares the Xmx setting of all VMs that use the free Plumbr. There is no way to know if these settings are used in production or someone just downloaded Plumbr for an evaluation. Most devs do not even bother to check how much memory their tomcat instances use, which would explain the size of the memory. They only ever tweak it when they run a load test or when the server runs out of memory. These metrics do not really reflect the heap sizes used in production, so I would not conclude that java does not need much memory. If anything, those that use Plumbr in evaluation mode do not run their JVMs with large heaps. You do not need a large heap to cause a OOM. Still, it is interesting to know what the Xmx settings are on these boxes.
- reeses 14y ago
  There's also a selection bias in effect. Plumbr is not yet a household name. Speculating wildly, I suspect that they don't have enough clients using it at scales that would provide meaningful statistical input. Many Java devs, when looking for object/memory/resource leakage, will turn to the well-known general purpose tools, such as JProbe, YourKit, Introscope, or even just JVM profiling output and verbose gc. Crazy people will start using DTrace or JMX hooks. The rest will just say they need a hardware refresh. As you say, this is an analysis of metrics gathered from people looking for a 'free' solution. The reason for the 'small' mx settings could be that developers are finding ways around procurement to find leaks on the same machine running their IDE, email, browser, etc.

57 points by ivom2gi 14y ago

said no one ever?

Umm. I trying to figure out how that title comes from what I just read in that article. The article shows a couple graphs comparing the max heap size and the max PermGen size of ~1000 different installations of java application servers. So? How can you state that java doesn't need that much memory after all? After all what? I know we've run out of PermGen with the JVM set to anything less than 192mb. We've got a pretty large app that (unfortunately) depends on a load of third party libraries. Too many libraries for my taste but that isn't my call. So, we must have this set or the server won't even start. All applications are different and have different memory requirements. Too low of a setting and you are constantly thrashing or running out of memory. Too large and you have huge garbage collection times. It has to be tuned. Now, I've heard (as I haven't really looked into it yet) that the JVM in the JDK 8 distribution has gotten rid of PermGen setting. So, I'm curious to know what 'they' are doing now. Is the G1 garbage collector the new default in JDK 8? Does that not have the PermGen or is this something different? Anyway, I don't know what this post is about yet. They probably should have just finished the thing instead of saying: "If you managed to get this far, then you are most likely interested to hear about our forthcoming posts. Stay tuned by subscribing to our Twitter feed." It was worthless.

tiemand 14y ago
I concur! Claiming that Java is not "as memory intensive as thought" means to me that they compared the memory usage profile of java applications with similar applications developed in other languages.
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.
millerm 14y ago
Replying to myself as I see the title has changed. That makes more sense. Now my comment seems out of context. I had no idea you could change the title of a submission, especially after people commented on it. That's actually scary.

bjoernbu 14y ago

The HN headline is somewhat misleading. It is different from the original article and I was expecting some neat techniques to overcome the typical memory issues: Everything is an object, generics need wrapper classes, padding everywhere. Those make HashMap<Integer>, ArrayList<Integer> or even "two dimensional arrays" a bad joke compared to C(++) equivalents. Projects like Lucene have to rewrite standard library eqiuvalents for specific cases since otherwise so much performance would be lost. Examinating app server -Xmx settings is more handwaving than anything. Especially people that refrain from doing certain things in java due to memory issues, have a completely misleading influence on such a metric.

_pmf_ 14y ago

It would also not hurt to mention the topic of virtual memory vs. "memory usage issue" here.

sil3ntmac 14y ago

Sorry for my naivety, but when does Java use the stack? Only for primitive operations?

pkolaczk 14y ago
If you turn Escape Analysis on, it allocates objects not escaping the local method scope on the stack.

philippelh 14y ago

Funny, isn't it? "...whether it is a 32 or 62-bit infrastructure..." and a bit later... "And those two who think 258MB is better – are you just bad at calculating the powers of two..."

priitp 14y ago
Well spotted :)
ivom2gi 14y ago
Congrats! You were the first one to spot the easter egg we planted, if you contact us referring to your original comment you can have the Plumbr for free for one year.

martinced 14y ago

PermGen, as if all the JVMs out there were Sun/Oracle or the OpenJDK ones ; )

pjmlp 14y ago
I still don't understand how developers fail to be aware of the amount of JVMs and even native compilers available for Java out in the wild.

cagenut 14y ago

I have the opposite problem, I can't get java to use "enough" memory. Every time we double it in production that leads to another few weeks of re-jiggering jvm flags and ratios and grepping&graphing the garbage collection log or staring at visualgc for days. We're thinking of giving up on scaling above 16gb/jvm and going to something crazy like 16x2gb jvms. Treat them like the worlds biggest mongrel and let the loadbalancer sort it out.

ivom2gi 14y ago
That is indeed our experience as well. Going beyond 8-12GB of heap starts to produce all kind of weird side effects. So our best recommendation is to scale vertically on the heap size ...
theatrus2 14y ago
Note that there is a cliff at about 20GB with +CompressedOoops, as the larger heap makes object reference compression impossible, so references return to a full machine word (8 bytes), which depending on your workload and code, can be significant.
dcminter 14y ago
It does irritate me that the Sun JVMs do not offer any flag to specify the heap size along the lines of "limited only by the environment" rather than obliging an upper limit to be specified.
pdog 14y ago
Honestly, if you really need your JVM to scale above 16 GBs of heap memory, you should go for something like the Zing JVM[1] from Azul Systems. However, the standard JVMs should suffice for 99% of workloads. [1]: http://www.azulsystems.com/products/zing/virtual-machine http://www.azulsystems.com/products/zing/virtual-machine
- aut0mat0n1c 14y ago
  Huh.. thanks for this. Never heard of zing, looks worth a test drive.

deleted 14y ago

[deleted]

cinbun8 14y ago

The post compares the Xmx setting of all VMs that use the free Plumbr. There is no way to know if these settings are used in production or someone just downloaded Plumbr for an evaluation. Most devs do not even bother to check how much memory their tomcat instances use, which would explain the size of the memory. They only ever tweak it when they run a load test or when the server runs out of memory. These metrics do not really reflect the heap sizes used in production, so I would not conclude that java does not need much memory. If anything, those that use Plumbr in evaluation mode do not run their JVMs with large heaps. You do not need a large heap to cause a OOM. Still, it is interesting to know what the Xmx settings are on these boxes.

reeses 14y ago
There's also a selection bias in effect. Plumbr is not yet a household name. Speculating wildly, I suspect that they don't have enough clients using it at scales that would provide meaningful statistical input. Many Java devs, when looking for object/memory/resource leakage, will turn to the well-known general purpose tools, such as JProbe, YourKit, Introscope, or even just JVM profiling output and verbose gc. Crazy people will start using DTrace or JMX hooks. The rest will just say they need a hardware refresh. As you say, this is an analysis of metrics gathered from people looking for a 'free' solution. The reason for the 'small' mx settings could be that developers are finding ways around procurement to find leaks on the same machine running their IDE, email, browser, etc.