Сборка мусора G1GC в Кассандре

Question

Мы планируем переместить GC из CMS в G1GC. А также из dse в apache эти параметры все еще необходимы, если мы перейдем на G1GC.Как эти параметры повлияли на сборку мусора при использовании G1GC

-XX:ThreadPriorityPolicy=42
-XX:+HeapDumpOnOutOfMemoryError
-Xss256k

# Larger interned string table, for gossip's benefit (CASSANDRA-6410)
-XX:StringTableSize=1000003
-XX:+AlwaysPreTouch
# Disable biased locking as it does not benefit Cassandra.
-XX:-UseBiasedLocking

`# Enable thread-local allocation blocks and allow the JVM to automatically
-XX:+UseTLAB
-XX:+ResizeTLAB
-XX:+UseNUMA
-XX:+PerfDisableSharedMem
-Djava.net.preferIPv4Stack=true`

Answer 1

Те имеют небольшую разницу между CMS и G1.

TLAB такие же, как CMS, это может помочь, предоставляя потокам каждый буфер, который они могут выделить непосредственно в пространстве eden, что означает отсутствие конкуренции или требований для безопасного распределения потоков (намного быстрее). Однако, если у вас много активных потоков (например, большой кластер с> 1000 активных клиентов), так как каждый буфер потока будет маленьким, а изменение размера станет неточным, поскольку разные потоки станут активными в разное время. Также, если происходят большие вставки, распределение не помещается в буфере и в конечном итоге выделяется в общих пространствах. Тем не менее, почти всегда лучше работать с TLAB / resize.

UseBiasedLocking также как и в CMS, синхронизации не так много, и паузы STW могут влиять на ситуацию.

UseNUMA не работает с g1 или cms, это только для параллельного коллектора. Установка этого ничего не делает

PerfDisableSharedMem жертвует вашей способностью отлаживать и диагностировать проблемы производительности в обмен на предотвращение возможной паузы при сбросе hsperfdata

preferIPv4Stack не использовать ipv6