Memory statistics are not detailed enough to do memory tuning

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Just look at the graphs, it only shows a wholelistic memory number
2.
3.

What is the expected output? What do you see instead?
memory break down for each pool as each pool has to be tuned separately and 
each pool can crash the server individually upon filling.

What version of the product are you using? On what application server, JDK,
operating system? N/A

Please provide any additional information below.

Patch set attached which removes the old "all memory" and "permgen" hard coded 
items, it dynamically looks up all the memory pools and prints them. (This is 
required because the memory pools change depending on the JVM you're running, 
even with just the SUN jvm if you use client v.s. server the number of pools 
and the name and types of pools change.

Original issue reported on code.google.com by r6squee...@gmail.com on 17 Feb 2012 at 4:21

Attachments:

• memory_pools.patch

[GoogleCodeExporter]

are you talking about eden, survivor, tenured, as well as permgen and codecache 
pools? If so, that would be a great addition.

Of particular note, I know some sysadmin's don't always recognize/see the 
permgen and codecache memory usage as it is outside of heap but still takes 
system memory...when they are squeezing down memory in confined virtual 
environments, having all this information taken into consideration would be 
great (particularly when dealing with hot-deploy filling up permgen issues 
being a different problem than heap memory, again easier graphs for server 
administrators to more easily monitor for them to understand).

Original comment by binarymo...@gmail.com on 17 Feb 2012 at 3:44

[GoogleCodeExporter]

Of note, the 'wholelistic' memory number is good for the server/sysadmin *if* 
it contains permgen and codecache.  I would rather keep that as a full one, 
with breakdowns more for developers for tuning and permgen nearby the 
wholeistic to easily see spikes that are likely from hot-deploys.

Original comment by binarymo...@gmail.com on 17 Feb 2012 at 3:48

[GoogleCodeExporter]

Original comment by evernat@free.fr on 19 Feb 2012 at 10:12

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

yes I do mean eden,survivor, old gen, and permgen and code cache, but those 
don't always exist, it depends on the jvm configuration so you can't hard code 
that. If you're running the sun-server-jvm i.e. -server then it will most 
likely be the 5 mentioned there.

As for the wholelistic approach, I'm not sure it makes sense to just add all 
the pools up. If your permgen is 32mb and your old-gen is 512mb. You can crash 
your jvm at 33mb of usage out of what would appear to be over 512mb.

This is true even of the eden and old-gen, if your eden is 64mb and your 
old-gen is 512mb, your system will thrash and most likely crash if the eden 
fills, i.e. 65mb usage of a total of over 512mb. The converse is also true, if 
you configure 256mb of eden and 512mb of old gen, if you fill the old gen, you 
can crash the server at 513 / 768 mb usage.

Original comment by r6squee...@gmail.com on 20 Feb 2012 at 12:28

[GoogleCodeExporter]

The JavaMelody project has moved. Follow this issue at
https://github.com/javamelody/javamelody/issues/182

Original comment by evernat@free.fr on 12 Jul 2015 at 10:12