There is a time key in GC.stat that gives us the total time spent in GC. However, we don't know what proportion of the time is spent between marking and sweeping. This makes it difficult to tune the GC as we're not sure where to focus our efforts on.
This PR adds keys marking_time and sweeping_time to GC.stat for the time spent marking and sweeping, in milliseconds.
There is a time key in GC.stat that gives us the total time spent in
GC. However, we don't know what proportion of the time is spent between
marking and sweeping. This makes it difficult to tune the GC as we're
not sure where to focus our efforts on.
This PR adds keys marking_time and sweeping_time to GC.stat for the
time spent marking and sweeping, in milliseconds.
You can show your support for this issue by clicking "like" in the top right corner
Aha - I did not notice that before.
could you please refrain from commenting unless it's meaningfully contributing
to the discussion?
This is a situational question, though, as to what is to be considered "meaningful".
Ultimately it taps into being able to provide feedback about feature set xyz, or
not being able to provide feedback.
But, before this is misunderstood: I do not mind using the "Like" part for short
feedback.
Is compaction time classified as marking_time or sweeping_time?
It will be part of sweeping_time. I think it's not very accurate to have a compacting_time because we do sweeping during compaction, so I chose to put compaction time in sweeping_time. It might make sense to have compacting_time in the future, but since it's disabled by default and I'm not aware of any production services using auto-compaction in production (we only run GC.compact before forking here at Shopify), so we don't need this data right now.
does the current patch (already merged) split it?
I refactored the code so that the marking and sweeping phases are separated (in d7c1ca4.
Updated by 
Updated by 
Updated by 
Updated by 
Updated by