Hi team,
While using vtprotobuf, I've encountered some memory leak issues that appear to be caused by objects taken from the pool not being returned properly.
To help identify such cases earlier and monitor object pool usage more effectively, it would be extremely useful to expose metrics around:
Number of objects taken from the pool
Number of objects returned to the pool
(Optionally) Grouped by object type
Suggestion:
From what I understand of the codebase, this could potentially be implemented by:
Modifying the generator function of the pool to increment a "taken" counter.
Enhancing the ReturnToVTPool template to increment a "returned" counter.
These stats could be exposed via:
Built-in Prometheus-compatible metrics, e.g.:
vtprotobuf_pool_taken_total{type="X"}
vtprotobuf_pool_returned_total{type="X"}
Or alternatively, just simple internal counters/logs that can be queried or hooked by applications.
This feature would be a big help in diagnosing leaks or verifying that pooled object usage is balanced.
Let me know your thoughts — happy to discuss further or contribute a PR if this makes sense. I can work on this, if folks feel this feature helps. Or if there is already any alternative, please help me out.
Thanks!
Hi team,
While using vtprotobuf, I've encountered some memory leak issues that appear to be caused by objects taken from the pool not being returned properly.
To help identify such cases earlier and monitor object pool usage more effectively, it would be extremely useful to expose metrics around:
Number of objects taken from the pool
Number of objects returned to the pool
(Optionally) Grouped by object type
Suggestion:
From what I understand of the codebase, this could potentially be implemented by:
Modifying the generator function of the pool to increment a "taken" counter.
Enhancing the ReturnToVTPool template to increment a "returned" counter.
These stats could be exposed via:
Built-in Prometheus-compatible metrics, e.g.:
vtprotobuf_pool_taken_total{type="X"}
vtprotobuf_pool_returned_total{type="X"}
Or alternatively, just simple internal counters/logs that can be queried or hooked by applications.
This feature would be a big help in diagnosing leaks or verifying that pooled object usage is balanced.
Let me know your thoughts — happy to discuss further or contribute a PR if this makes sense. I can work on this, if folks feel this feature helps. Or if there is already any alternative, please help me out.
Thanks!