We use LatencyUtils with redis client lettuce.
Lettuce will drop LatencyStats every 10 min, and call LatencyStats's stop method.
After some dig, I found out that LatencyStats's stop only remove LatencyStats$PauseTracker from PauseDetector, TimeCappedMovingAverageIntervalEstimator$PauseTracker left untouched. When TimeCappedMovingAverageIntervalEstimator got garbage collected, weak reference TimeCappedMovingAverageIntervalEstimator$PauseTracker will remove itself from PauseDetector and will be collected at next gc.
In my scenario，we use g1 as collector. 10 min is too long and TimeCappedMovingAverageIntervalEstimator$PauseTracker is already promoted to old gen. G1 only collects part of old gen when mixed gc, so old gen is grow slowly. This will in turn affect gc time and throughput.
Is it better to eager clean TimeCappedMovingAverageIntervalEstimator$PauseTracker when stop is called ?
qsLI
commented
6 months ago
We use LatencyUtils with redis client lettuce. Lettuce will drop LatencyStats every 10 min, and call LatencyStats's stop method.
After some dig, I found out that LatencyStats's stop only remove LatencyStats$PauseTracker from PauseDetector, TimeCappedMovingAverageIntervalEstimator$PauseTracker left untouched. When TimeCappedMovingAverageIntervalEstimator got garbage collected, weak reference TimeCappedMovingAverageIntervalEstimator$PauseTracker will remove itself from PauseDetector and will be collected at next gc.
In my scenario，we use g1 as collector. 10 min is too long and TimeCappedMovingAverageIntervalEstimator$PauseTracker is already promoted to old gen. G1 only collects part of old gen when mixed gc, so old gen is grow slowly. This will in turn affect gc time and throughput.
Is it better to eager clean TimeCappedMovingAverageIntervalEstimator$PauseTracker when stop is called ?