fisk commented on code in PR #3696:
URL: https://github.com/apache/cassandra/pull/3696#discussion_r1887966338
##########
src/java/org/apache/cassandra/config/Config.java:
##########
@@ -543,9 +543,12 @@ public static class SSTableConfig
public volatile DurationSpec.IntMinutesBound index_summary_resize_interval
= new DurationSpec.IntMinutesBound("60m");
@Replaces(oldName = "gc_log_threshold_in_ms", converter =
Converters.MILLIS_DURATION_INT, deprecated = true)
- public volatile DurationSpec.IntMillisecondsBound gc_log_threshold = new
DurationSpec.IntMillisecondsBound("200ms");
+ public volatile DurationSpec.IntMillisecondsBound gc_log_threshold = new
DurationSpec.IntMillisecondsBound("20s");
Review Comment:
A big difference regarding GC duration comparing stop-the-world GC to ZGC is
that STW GC operations try to finish GC pauses as fast as possible with as many
threads as possible, to reduce latency impact due to pausing the program. If it
takes too long, advanced STW collectors like G1 will try to be incremental
instead, splitting the work over multiple GC pauses. ZGC, being a concurrent
collector, aims at doing the opposite: use as few threads as we can get away
with, preferring to take longer instead. There is also no need for incremental
GC in the same way. Here the roles are quite reversed: we don't pause the
program and hence don't improve latency by using more threads. Conversely, in
the concurrent context, latencies get worse when we throw more threads at the
problem, due to stealing CPU resources from the program threads. ZGC prefers to
stay in the background chipping away at the GC work with a single thread
constantly running, compared to having bursts of CPU utilization i
n order to finish doing GC faster than was really needed. Therefore, GC
duration will look longer, but is also not really going to be indicative of any
problem the way that it might have been before.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
