#cassandra
#cassandra
Вопрос:
Недавно у нас начались проблемы с нашим кластером Cassandra. Может быть, у кого-то есть идеи о том, как это исправить. Мы запускаем Cassandra 3.11.7 в кластере из 40 узлов. Мы используем коэффициент репликации = 3 и чтение / запись на уровне КВОРУМА согласованности.
Недавно на одном узле произошел внезапный скачок загрузки процессора, который затем продолжался некоторое время. В течение этого периода мы можем наблюдать множество отброшенных и поставленных в очередь мутаций. Если мы перезапустим Cassandra на проблемном узле, один или два других узла начнут страдать от той же проблемы. Мы изучили файлы журналов и шаблоны доступа и пока не смогли найти причину.
Каковы могут быть наиболее распространенные причины такого поведения? На что нам следует обратить более пристальное внимание? У кого-нибудь уже был подобный опыт?
Ответ №1:
Если мы перезапустим Cassandra на проблемном узле, один или два других узла начнут страдать от той же проблемы.
Прежде всего, когда проблема возникает на одном узле, его перезапуск обычно ничего не дает. В случае чего, вы очистите кучу JVM … которая будет быстро повторно заполнена при запуске. Серьезно, не ожидайте, что перезапуск узла что-либо исправит.
У кого-нибудь уже был подобный опыт?
Да, несколько раз. Для вещей, не связанных с Cassandra:
- Вы работаете в облачной среде? Запустите
iostat
и поищите такие вещи, как высокие процентыiowait
иsteal
. Иногда общие ресурсы плохо взаимодействуют с другими. Если у вас нетiostat
, получите это (yum install -y sysstat
). - Проверьте cron для всех пользователей. Однажды у нас возникла проблема с установкой средства проверки целостности файлов как части нашего базового образа, и оно сделало именно то, о чем вы говорите.
Каковы могут быть наиболее распространенные причины такого поведения? На что нам следует обратить более пристальное внимание?
Для проблем, связанных с Cassandra, я вижу несколько возможностей:
- Ремонт. Проверьте, выполняется ли на узле восстановление. Вы можете просмотреть вычисления дерева Merkle с помощью
nodetool compactionstats
и восстановить потоки с помощьюnodetool netstats
. - Уплотнения. Проверьте
nodetool compactionstats
. Если это все, вы можете попробовать снизить пропускную способность сжатия, чтобы это не повлияло на нормальные операции. - Сборка мусора. Проверьте
gc.log.*
файлы. Если это GC, это обычно можно исправить, прочитав и скорректировав настройки GC. Если в вашей команде нет никого, кто является экспертом по JVM GC, я рекомендую использовать G1GC, поскольку это избавляет от многих догадок.
Обратите внимание, что все, что я упомянул выше, никогда не может быть исправлено перезагрузкой. На самом деле, вполне вероятно, что он вернется к тому, на чем остановился.
Комментарии:
1. Большое вам спасибо за все подсказки. Это помогло нам уменьшить карту проблем. Поскольку у нас нет проблем с cron, ремонтами или уплотнениями, мы более внимательно рассмотрели запросы наших клиентов, использующие
nodetool toppartitions
проблемные узлы. В конце концов мы выяснили, что причина в действительно огромных объемах данных, которые мы постоянно обновляем из-за какой-то ошибки в логике нашего приложения. После исправления этой ошибки скачки загрузки исчезли.