Почему мой узел Cassandra застрял с увеличением MutationStage?

Я использую Cassandra для хранения фотографий. В настоящее время мы осуществляем массовую миграцию изображений из старой системы. Все работает отлично на некоторое время, но в конечном итоге мы получим TimedOutException при сохранении, которое я предполагаю, потому что рабочая очередь была заполнена.

Однако, после ожидания (несколько часов) для его завершения, ситуация остается неизменной (она не восстанавливается после остановки миграции)

Кажется, что проблема tpstats только с одним узлом, на котором команда tpstats показывает следующие данные

Cassandra tpstats

Ожидаемые операции MutationStage продолжают увеличиваться, даже несмотря на то, что мы прекратили вставки за несколько часов назад.

Что именно это значит? Что такое MutationStage?

Что я могу проверить, чтобы понять, почему он так долго не стабилизируется? Все остальные серверы в кольце находятся в 0 незавершенных операциях.

Любая новая вставка, которую мы TimedOutException исключение TimedOutException....

Это информация о кольцах, если она полезна

enter image description here
(узел с проблемами является первым)

EDIT: последние строки в журнале следующие.

INFO [OptionalTasks:1] 2013-02-05 10:12:59,140 MeteredFlusher.java (line 62) flushing high-traffic column family CFS(Keyspace='pics_persistent', ColumnFamily='master') (estimated 92972117 bytes)  
INFO [OptionalTasks:1] 2013-02-05 10:12:59,141 ColumnFamilyStore.java (line 643) Enqueuing flush of [email protected](74377694/92972117 serialized/live bytes, 141 ops)
INFO [OptionalTasks:1] 2013-02-05 10:14:49,205 MeteredFlusher.java (line 62) flushing high-traffic column family CFS(Keyspace='pics_persistent', ColumnFamily='master') (estimated 80689206 bytes)
INFO [OptionalTasks:1] 2013-02-05 10:14:49,207 ColumnFamilyStore.java (line 643) Enqueuing flush of [email protected](64551365/80689206 serialized/live bytes, 113 ops)
WARN [MemoryMeter:1] 2013-02-05 10:16:10,662 Memtable.java (line 197) setting live ratio to minimum of 1.0 instead of 0.0015255633589225548
INFO [MemoryMeter:1] 2013-02-05 10:16:10,663 Memtable.java (line 213) CFS(Keyspace='pics_persistent', ColumnFamily='master') liveRatio is 1.0 (just-counted was 1.0).  calculation took 38ms for 86 columns
INFO [OptionalTasks:1] 2013-02-05 10:16:33,267 MeteredFlusher.java (line 62) flushing high-traffic column family CFS(Keyspace='pics_persistent', ColumnFamily='master') (estimated 71029403 bytes)
INFO [OptionalTasks:1] 2013-02-05 10:16:33,269 ColumnFamilyStore.java (line 643) Enqueuing flush of [email protected](56823523/71029403 serialized/live bytes, 108 ops)
INFO [ScheduledTasks:1] 2013-02-05 11:36:27,798 GCInspector.java (line 122) GC for ParNew: 243 ms for 1 collections, 1917768456 used; max is 3107979264
INFO [ScheduledTasks:1] 2013-02-05 13:00:54,090 GCInspector.java (line 122) GC for ParNew: 327 ms for 1 collections, 1966976760 used; max is 3107979264

ОТВЕТЫ

Ответ 1

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

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

Я не знаю, почему один из узлов перегружен, потому что может быть несколько причин:

  • узел медленнее остальных (другое оборудование или другая конфигурация)
  • кластер не сбалансирован должным образом (однако начало вашего вывода кольца nodetool предполагает, что это не так)
  • вы направляете все свои записи на этот конкретный узел, а не распределяете их по всем узлам одинаково, например, с помощью циклического
  • вы сконфигурировали слишком большой общий размер или размер кэша memtables для слишком маленького полного пространства кучи, и ваши узлы борется с GC, и только что случилось, что этот был первым, кто попал в спираль смерти GC