In analyzing Java GC behavior, some tools has the metric "garbage collection rate" (an example would be in figure 19. from http://www.ibm.com/developerworks/java/library/j-ibmtools2/#fig19) of which the unit is MB/sec.
It's a rarely metric compared to others, like GC utilization. It looks like representing how fast GC cleans up. But does it provide any benefit? Or how should it be best analyzed?
You can find it used to spot some causes of JVM slowdown in performance analysis.
(Extract, emphasis mine)
garbage collection rate broken down by generation.
Remember that Suns’ JVMs (1.3+) are generational and that the heap is broken into a ‘young generation’ and an ‘old generation’ according to object ‘age’.
By default, two different GC algorithms are used to manage each of the two generations;
- the young generation uses a Copying Collector and
- the old generation uses a Mark Compact Collector.
The specifics of these and other GC algorithms mentioned in this blog can be found on Sun’s excellent Turbo-charging Java HotSpot Virtual Machine article.
[...] How can we tell how much impact this increased Old Generation GC activity had on the application?
Well, if we correlate the data that we now know with another PerformaSure graph,; the GC Overhead graph, we can determine the impact of the increased GC activity.We can clearly see the overhead increasing in tandem with the Old Generation GC rate, eventually reaching a level of 100% overhead.
Referring the the Active Session Count graph, we can see that the increase in GC activity and the associated overhead actually coincides with the coming online of another user community, increasing the concurrent number of active sessions from approximately 200 to 250 and depending on circumstances and workload, sometimes 300 sessions.
Since it is MB/sec I would guess that it means "MB of memory freed by garbage collection runs per second".
As for how meaningful this is: The chart you linked to also provides "number of garbage collections" and "mean garbage collection pause [ms]". You should look at all these numbers together to figure out if there is a problem.
By itself, the metric probably just shows if you are using a lot of "temporary" objects (so that big chunks can be freed) or not. If you have a lot of pauses and collection runs, but only relatively few MB freed, you are reaching the memory capacity and need to either add more memory or scale down your consumption of it.
Yes, taking a look at the garbage collection rate makes sense if your goal is to scale to support many users in parallel.
Using the unit Mbyte/second usually is not very helpful.
I usually recommend to try to stay under 10 Mbyte per user interaction.
You need to be carefully not trying too hard to minimize Garbage, because it can happen that by doing so you may limit concurrency. Markus (http://kohlerm.blogspot.com/)
Besides obvious usage of this metric for understanding short-lived objects usage of programs, most of the tools having this metric, garbage collection rate in MB/sec, use it as a way to measure how well applications perform.
The assumption made is that whatever garbage produced is equal to garbage generated, which also represents how well applications run (the more efficient applications run the faster it generates garbage). Usually these tools compare this metric from different versions of the program to determine which runs more efficient (the higher number the better).
A typical usage scenario would be comparing before/after number of it for a code fix. If the number goes up, it usually (you knows, not always) means better.