You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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.
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.
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.
The text was updated successfully, but these errors were encountered: