Apache Cassandra: подсказки создаются постоянно, даже если все узлы работают

У меня есть кластер apache cassandra 2.0.6 из 5 узлов с 48 ГБ оперативной памяти и каталогом данных объемом 2 ТБ, а также каталог журнала фиксации объемом 93 ГБ. Пространство кучи JVM для cassandra составляет 8 ГБ. Я использую плагин JVisualVM Mbeans для мониторинга показателей cassandra. Подсказки постоянно создаются на всех узлах, даже если все узлы работают. И поскольку подсказки создаются во время записи данных, через некоторое время я сталкиваюсь с подавляющим исключением надгробной плиты, которое прерывает запросы. Может ли кто-нибудь объяснить, почему это происходит, и предоставить средство для того же.


person venkat sam    schedule 25.08.2014    source источник
comment
Вы видите что-то подозрительное в своих журналах?   -  person Mikhail Stepura    schedule 26.08.2014
comment
Да. Мои журналы заполнены надгробиями, подавляющими исключениями каждые 10 минут.   -  person venkat sam    schedule 28.08.2014
comment
ОШИБКА [HintedHandoff:1308] 2014-08-28 06:34:33,727 CassandraDaemon.java (строка 196) Исключение в потоке Thread[HintedHandoff:1308,1,main] ОШИБКА [HintedHandoff:1309] 2014-08-28 06:44 :33,077 SliceQueryFilter.java (строка 200) Просканировано более 200 000 надгробий в system.hints; запрос прерван (см. tombstone_fail_threshold) ОШИБКА [HintedHandoff:1309] 2014-08-28 06:44:33,078 CassandraDaemon.java (строка 196) Исключение в потоке Thread[HintedHandoff:1309,1,main]   -  person venkat sam    schedule 28.08.2014
comment
Ну, это ясно. Вы видите, что что-то, связанное с узлом, не работает?   -  person Mikhail Stepura    schedule 28.08.2014
comment
Прямо сейчас я не получаю ошибку node down. Но неделю назад я получил ошибку о том, что Gossiper не работает, а Native thrift не работает. Мои старые журналы были очищены, поэтому я не мог предоставить точный отчет журнала.   -  person venkat sam    schedule 28.08.2014


Ответы (1)


Проблема с подавляющим исключением подсказок надгробной плиты известна, и существуют Jira для исправления ситуации.

Вы получаете ОШИБКУ надгробия или ПРЕДУПРЕЖДЕНИЕ о надгробии в своих журналах? Если вы нажимаете ОШИБКУ надгробия, вам нужно временно увеличить порог, чтобы избежать ошибки и разрешить обработку ваших подсказок.

Если ваш кластер продолжает регулярно генерировать подсказки при нормальной работе, то он явно каким-то образом перегружен, и эту проблему необходимо решить, чтобы подсказки не требовались для нормальной работы. Наиболее вероятная причина — длительные паузы GC. Видите ли вы сообщения «GC for» в системных журналах? Если да, то сколько в среднем в мс паузы и как часто? Сколько стоит ParNew против ConcurrentMarkSweep?

person dkblinux98    schedule 27.08.2014
comment
Спасибо за ответ. Я получаю сообщения об ошибках Tombstone без предупреждения. Я попытался увеличить tombstone_failure_threshold с 100000 до 200000, но, как вы сказали, это временно устранило ошибку, но через несколько часов ошибка начала появляться снова. - person venkat sam; 30.08.2014
comment
Что касается пауз GC: в среднем ParNew занимает 300 мс и запускается каждую минуту. ConcurrentMarkSweep занимает 250 мс и запускается случайным образом в среднем каждые 10 минут. Сейчас у нас write_request_timeout_in_ms: 2000 и мы планируем увеличить его до 10000 мс (при условии, что хинты генерируются из-за ошибки записи, так как в моем кластере запись происходит со скоростью 170 ГБ в день). Не могли бы вы объяснить, как GC вызывает подсказки, инициирует подсказки, а также в порядке ли мои текущие значения параметров ParNew и ConcurrentMarkSweep, если не как их настроить? - person venkat sam; 30.08.2014
comment
Для справки я предоставляю системный журнал ниже - person venkat sam; 30.08.2014
comment
INFO [ScheduledTasks:1] 2014-08-27 08:56:51,354 GCInspector.java (строка 116) GC для ParNew: 304 мс для 1 коллекции, 5079302472 используется; макс. 8422162432 INFO [ScheduledTasks:1] 2014-08-27 08:57:20,763 GCInspector.java (строка 116) GC для ConcurrentMarkSweep: 203 мс для 1 коллекции, 5366351976 использовано; макс. 8422162432 INFO [ScheduledTasks:1] 2014-08-27 08:58:13,529 GCInspector.java (строка 116) GC для ParNew: 231 мс для 1 коллекции, 2170074400 использовано; макс 8422162432 - person venkat sam; 30.08.2014
comment
Долгие паузы ParNew и CMS заставят узел отображаться для координатора и, таким образом, сохранять подсказки. Таким образом, улучшение GC также улучшит подсказки и общую производительность записи. Вероятно, вам нужно увеличить HEAP_NEWSIZE в cassandra-env.sh. Попробуйте установить для него значение 1024M для запуска, если сейчас оно составляет 800M, и выполните последовательный перезапуск и отслеживайте события GC в журналах. - person dkblinux98; 01.09.2014