3 ms·
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 download
by 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 agoThere'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.