Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a metric for tracking heap size after last gc event #5311

Open
lenin-jaganathan opened this issue Jul 22, 2024 · 2 comments
Open

Add a metric for tracking heap size after last gc event #5311

lenin-jaganathan opened this issue Jul 22, 2024 · 2 comments
Labels
waiting for team An issue we need members of the team to review

Comments

@lenin-jaganathan
Copy link
Contributor

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
@shakuzen
Copy link
Member

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 shakuzen added waiting for feedback We need additional information before we can continue and removed waiting-for-triage labels Jul 22, 2024
@lenin-jaganathan
Copy link
Contributor Author

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.

@shakuzen shakuzen added waiting for team An issue we need members of the team to review and removed waiting for feedback We need additional information before we can continue labels Jul 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
waiting for team An issue we need members of the team to review
Projects
None yet
Development

No branches or pull requests

2 participants