Частые шипы в Кассандре латентность записи - PullRequest
0 голосов
/ 18 сентября 2018

В производственном кластере задержка кластерной записи часто увеличивается от 7 мс до 4 с.Из-за этого клиенты сталкиваются с большим количеством тайм-аутов чтения и записи.Это повторяется каждые несколько часов.

Наблюдение: задержка записи кластера (99-й процентиль) - локальная задержка записи 4Sec (99-й процентиль) - согласованность чтения и записи 10 мс - local_one Всего узлов - 7

Iпопытался включить трассировку с помощью settraceprobability в течение нескольких минут и заметил, что большая часть времени затрачивается на межузловую связь

 session_id                           | event_id                             | activity                                                                                                                    | source        | source_elapsed | thread
--------------------------------------+--------------------------------------+-----------------------------------------------------------------------------------------------------------------------------+---------------+----------------+------------------------------------------
 4267dca2-bb79-11e8-aeca-439c84a4762c | 429c3314-bb79-11e8-aeca-439c84a4762c | Parsing  SELECT * FROM table1 WHERE uaid = '506a5f3b' AND messageid >= '01;'  | cassandranode3 |              7 |                     SharedPool-Worker-47
 4267dca2-bb79-11e8-aeca-439c84a4762c | 429c5a20-bb79-11e8-aeca-439c84a4762c |                                                                                                         Preparing statement | Cassandranode3 |             47 |                     SharedPool-Worker-47
 4267dca2-bb79-11e8-aeca-439c84a4762c | 429c5a21-bb79-11e8-aeca-439c84a4762c |                                                                                            reading data from /Cassandranode1 | Cassandranode3 |            121 |                     SharedPool-Worker-47
 4267dca2-bb79-11e8-aeca-439c84a4762c | 42a38610-bb79-11e8-aeca-439c84a4762c |                                                                       REQUEST_RESPONSE message received from /cassandranode1 | cassandranode3 |          40614 | MessagingService-Incoming-/Cassandranode1
 4267dca2-bb79-11e8-aeca-439c84a4762c | 42a38611-bb79-11e8-aeca-439c84a4762c |                                                                                     Processing response from /Cassandranode1 | Cassandranode3 |          40626 |                      SharedPool-Worker-5

Я пытался проверить соединение между узлами Cassandra, но не увидел никаких проблем.Журналы Cassandra заполняются исключениями тайм-аута чтения, так как это довольно загруженный кластер с 30k операций чтения / сек и 10k операций записи / сек.

Предупреждение в system.log:

WARN  [SharedPool-Worker-28] 2018-09-19 01:39:16,999 SliceQueryFilter.java:320 - Read 122 live and 266 tombstone cells in system.schema_columns for key: system (see tombstone_warn_threshold). 2147483593 columns were requested, slices=[-]

Во времяspike the кластер просто останавливается и простые команды, такие как команда «use system_traces», также не работают.

cassandra@cqlsh:system_traces> select * from sessions ;
Warning: schema version mismatch detected, which might be caused by DOWN nodes; if this is not the case, check the schema versions of your nodes in system.local and system.peers.
Schema metadata was not refreshed. See log for details.

Я проверил версии схемы на всех узлах и одинаковые, но похоже, что во время выпуска Cassandra даже не в состояниичитать метаданные.

Кто-нибудь сталкивался с подобными проблемами?есть предложения?

1 Ответ

0 голосов
/ 19 сентября 2018

(из данных ваших комментариев выше). Длинные полные паузы gc могут определенно вызывать это.Добавьте -XX:+DisableExplicitGC, вы получаете полный GC из-за обращений к system.gc, что, скорее всего, происходит из-за глупой вещи DGC rmi, которая вызывается через регулярные промежутки времени, независимо от необходимости.С большой кучей это ОЧЕНЬ дорого.Это безопасно отключить.

Проверьте заголовок журнала gc, убедитесь, что минимальный размер кучи не установлен.Я бы порекомендовал установить -XX:G1ReservePercent=20

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...