Кассандра и сборщик мусора G1 останавливают мировое событие (STW)

У нас есть кластер Cassandra с 6 узлами, который интенсивно используется. Мы много раз сталкивались с событием остановки сборщика мусора, которое может занять до 50 секунд в наших узлах, в то время как узел Cassandra не отвечает, даже не принимает новые входы в систему.

Дополнительные детали:

  • Кассандра Версия: 3.11
  • Размер кучи = 12 ГБ
  • Мы используем сборщик мусора G1 с настройками по умолчанию.
  • Размер узлов: 4 ЦП 28 ГБ ОЗУ
  • Поведение G1 GC одинаково для всех узлов.

Любая помощь будет очень высоко ценится!

введите здесь описание изображения

введите здесь описание изображения

введите здесь описание изображения

введите здесь описание изображения

введите здесь описание изображения

Редактировать 1:

Проверяя статистику создания объектов, она совсем не выглядит здоровой.

введите здесь описание изображения

Редактировать 2:

Я попытался использовать настройки, предложенные Крисом Лофинком, вот отчет GC:

Использование рекомендуемых настроек CMS http://gceasy.io/my-gc-report.jsp?p=c2hhcmVkLzIwMTcvMTAvOC8tLWdjLmxvZy4wLmN1cnJlbnQtLTE5LTAtNDk=

Использование рекомендуемых настроек G1 http://gceasy.io/my-gc-report.jsp?p=c2hhcmVkLzIwMTcvMTAvOC8tLWdjLmxvZy4wLmN1cnJlbnQtLTE5LTExLTE3

Поведение остается в основном таким же:

  1. Старый Ген начинает заполняться.
  2. GC не может очистить его должным образом без полного GC и события STW.
  3. Полный сборщик мусора начинает занимать больше времени, пока узел полностью не перестанет отвечать.

Я собираюсь получить вывод cfstats для максимального размера раздела и надгробий на чтение как можно скорее и снова отредактировать сообщение.


cassandra garbage-collection cassandra-3.0 g1gc
person Scudeler    schedule 04.10.2017    source источник
comment
куча после GC увеличивается, поэтому либо вашему приложению просто нужно больше памяти, либо у вас есть утечка, либо cassandra настроена таким образом, что выделяет ресурсы таким образом, что G1 не может справиться. Эти случаи нельзя отличить только по этим графикам.   -  person the8472    schedule 04.10.2017
comment
каковы ваши текущие настройки GC?   -  person Chris Lohfink    schedule 04.10.2017
comment
Можете ли вы включить вывод cfstats для максимального размера раздела и надгробий на чтение? Сканирование надгробного камня и десериализация большого индекса раздела являются распространенными причинами высокой скорости выделения объектов. также комментарий выше, трудно сказать, как улучшить ваши GC, не зная текущих настроек   -  person Chris Lohfink    schedule 06.10.2017
comment
@ChrisLohfink Я пытался использовать настройки G1 GC по умолчанию, я играл с XX: MaxGCPauseMillis, но ничего не изменилось. Я отредактировал сообщение с отчетами GC, используя рекомендуемые настройки для G1 и CMS, и я собираюсь получить информацию, которую вы просили, как можно скорее.   -  person Scudeler    schedule 08.10.2017
comment
@the8472 похоже на утечку памяти (plumbr.eu/blog /memory-leaks/), не могли бы вы привести пример того, какие настройки Cassandra я могу проверить?   -  person Scudeler    schedule 08.10.2017
comment
Можете ли вы поделиться своей схемой и cfstats? Это похоже на проблему с широким разделом или надгробием, чтобы создать так много мусора. Дамп кучи был бы наиболее информативным, но он довольно большой и его трудно разделить.   -  person Chris Lohfink    schedule 09.10.2017

Ответы (2)


arrow_upward
3
arrow_downward

Вы смотрели на использование Zing? Подобные ситуации с Cassandra являются классическим вариантом использования, поскольку Zing принципиально устраняет все сбои, связанные с GC, в узлах и кластерах Cassandra.

Вы можете увидеть некоторые подробности о том, как и почему, в моем недавнем докладе «Понимание GC» от ​​JavaOne (https://www.slideshare.net/howarddgreen/understanding-gc-javaone-2017). Или просто перейдите к слайдам 56–60, чтобы получить результаты, относящиеся к Cassandra.

person Gil Tene    schedule 06.10.2017

arrow_upward
2
arrow_downward

Не зная, каковы ваши существующие настройки или возможные проблемы с моделью данных, вот предположение о некоторых консервативных настройках, которые можно использовать, чтобы попытаться уменьшить паузы эвакуации из-за нехватки места (проверьте журналы gc):

-Xmx12G -Xms12G -XX:+UseG1GC -XX:G1ReservePercent=25 -XX:G1RSetUpdatingPauseTimePercent=5 -XX:MaxGCPauseMillis=500 -XX:-ReduceInitialCardMarks -XX:G1HeapRegionSize=32m

Это также должно помочь уменьшить паузу в обновлении набора запоминания, которая становится проблемой, и уменьшить количество огромных объектов, которые могут стать проблемой в зависимости от модели данных. Убедитесь, что параметр -Xmn не установлен.

12Gb с C *, вероятно, больше подходит для использования CMS, вы, безусловно, можете получить лучшую пропускную способность. Просто нужно быть осторожным с фрагментацией с течением времени с довольно большими объектами, которые могут быть выделены.

-XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=55 -XX:MaxTenuringThreshold=3 -Xmx12G -Xms12G -Xmn3G -XX:+CMSEdenChunksRecordAlways -XX:+CMSParallelInitialMarkEnabled -XX:+CMSParallelRemarkEnabled -XX:CMSWaitDuration=10000 -XX:+UseCMSInitiatingOccupancyOnly -XX:+UseCondCardMark

Скорее всего, проблема с моделью данных или с недостаточной подготовкой.

person Chris Lohfink    schedule 04.10.2017