JVM-узел Cassandra зависает при восстановлении узла таблицей с материализованным представлением - PullRequest
Новая
       90

JVM-узел Cassandra зависает при восстановлении узла таблицей с материализованным представлением

1 голос
/ 04 апреля 2020

У меня кластер из 9 узлов на AWS. Недавно некоторые узлы вышли из строя, и я хочу восстановить кластер после перезапуска их. Но я обнаружил, что операция восстановления вызывает много запоминающегося гриппа sh, а затем JVM G C не удалось. Следовательно, узел зависает.

Я использую кассандру 3.1.0. 

java version "1.8.0_231"
Java(TM) SE Runtime Environment (build 1.8.0_231-b32)
Java HotSpot(TM) 64-Bit Server VM (build 25.231-b32, mixed mode)

Аппаратное обеспечение узла - 32 Гб памяти и 4 ядра процессора. Куча 16гб. Для каждого узла около 200 ГБ sstables.

JVM зависает очень быстро. После запуска процесса ремонта все работает. Я проверил память, процессор и IO. Стресса не найдено. По истечении случайного времени (задача потоковой передачи завершается) ожидающая задача memtableflushwriter очень быстро увеличивается, и затем G C не выполняется. Зависание JVM и создание heapdump. Когда возникла проблема, ЦП загружается с низкой нагрузкой, и я не могу найти задержку ввода / вывода для метрик диска AWS EBS.

Я проверил файл дампа кучи. Есть несколько больших памятных предметов ремонта стола. Размер памятных объектов составляет около 400 - 700 МБ. И памятные записки создаются за 20 секунд. Кроме того, я вижу более 12000 памятных записок. В этих memtables есть 6000 sstable_activity memtables.

Сначала я подозреваю, что записываемый грипп sh писатель является узким местом. Таким образом, я увеличиваю это до 4 потоков. И я удваиваю память узла. Но это не работает. Во время восстановления ожидающая задача быстро увеличивается, а затем узел снова зависает. Я также уменьшил диапазон маркеров восстановления, только один vnode, но все еще не удался.

Мы можем видеть некоторые журналы, подобные этому 

WARN [STREAM-IN-/10.0.113.12:7000] 2020-04-02 05:05:57,150 BigTableWriter.java:211 - Writing large partition ....

Пишущие sstables имеют 300 - 500 МБ. Какой-то большой достигает 2+ ГБ.

I go через исходный код кассандры. И я обнаружил, что sstables должны обрабатываться в обычном процессе записи, если таблица имеет материализованное представление. Таким образом, я подозреваю, что проблема возникает в завершенной стадии потоковой передачи.

После потоковой передачи функция обратного вызова приема загружает обновленные sstables раздела и создает мутацию при обычной записи. Таким образом, это увеличивает memtables в куче. Кроме того, он также вызывает flu sh (), которая создает дополнительные памятные таблицы помимо восстановленных таблиц. Размер мемаблиц превышает порог очистки. Так грипп sh называется. Но грипп sh не может освободить достаточно воспоминаний. Так много раз гриппа sh называется. С другой стороны, грипп sh также увеличит количество записываемых файлов.

Так кто-нибудь сталкивался с той же проблемой? Если мой вывод верен, как это исправить?

1 Ответ

1 голос
/ 04 апреля 2020

Восстановление в Cassandra не использует memtable - он использует тот же механизм потоковой передачи, который используется для bootstrap узлов и т. Д. c. Но если у вас есть большие перегородки, и они повреждены, то Кассандре нужно будет отправить их, а на стороне получателя потребуется построить вспомогательные структуры, например c. Дополнительную информацию о возможных проблемах с ремонтом можно найти в после публикации в блоге .

. Одним из возможных решений является использование восстановления диапазона, так что вы можете проверить только определенные c части жетон Но делать это вручную - утомительная задача, поэтому для автоматизации этого процесса лучше использовать такой инструмент, как Cassandra Reaper .

...