micrometer icon indicating copy to clipboard operation
micrometer copied to clipboard

Add a metric for tracking heap size after last gc event

Open lenin-jaganathan opened this issue 1 year ago • 2 comments

Please describe the feature request. In most cases for performance optimizations related to memory, it is necessary to understand the GC behavior and the memory allocation/reclamation behaviors. It is in this aspect, that analyzing the various heap region sizes after GC seems to be a very useful metric. The information can be obtained from MemoryPoolMXBean#getCollectionUsage on supported JVM's.

Related metrics in this space, but having the exact snapshot data post-GC helps in applying transformations/aggregations in the backend along with the memory pool names.

  • jvm.gc.memory.promoted
  • jvm.gc.memory.allocated
  • jvm.gc.max.data.size

lenin-jaganathan avatar Jul 22 '24 05:07 lenin-jaganathan

We also already provide jvm.gc.live.data.size in JvmGcMetrics with the description "Size of long-lived heap memory pool after reclamation". Is that not what you're looking for?

We've abstracted the memory pool name away so the same metric can be used with different GCs.

shakuzen avatar Jul 22 '24 08:07 shakuzen

It doesn't factor in the changes in survivor space. Also, I see most of the time it is not reporting values. longLivedAfter < longLivedBefore returns false and the metric seems to return zero.

Both seem to go away when we use the OperatingSystemMxBean. All the pre-computations are done away with and we can apply the aggregations at the back-end/UI with raw data.

lenin-jaganathan avatar Jul 22 '24 08:07 lenin-jaganathan