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
My team is using parallel-consumer in production, and we observed increasing memory usage over time in all of our services.
After monitoring the heap, we found that this stack trace was responsible for 96% of the heap size after 3 days of uptime:
This is reproducible locally. Whenever the parallel-consumer attempts to commit its offsets, it creates two new timers and adds them to the registeredMetrics list in PCMetrics, even if the exact tag combination already exists.
Keeping track of the registeredMetrics list shows this after 10 minutes (With a 1 second commit interval):
Changing the list to a set seems to fix the issue, but not sure if a more sophisticated method would be preferred.
The text was updated successfully, but these errors were encountered:
My team is using parallel-consumer in production, and we observed increasing memory usage over time in all of our services.
After monitoring the heap, we found that this stack trace was responsible for 96% of the heap size after 3 days of uptime:
This is reproducible locally. Whenever the parallel-consumer attempts to commit its offsets, it creates two new timers and adds them to the
registeredMetrics
list in PCMetrics, even if the exact tag combination already exists.Keeping track of the

registeredMetrics
list shows this after 10 minutes (With a 1 second commit interval):Changing the list to a set seems to fix the issue, but not sure if a more sophisticated method would be preferred.
The text was updated successfully, but these errors were encountered: