1. дома
  2. Вопрос и ответ
  3. Trouble tracing cassandra query

Trouble tracing cassandra query

2015-10-08 7 views
1

Я испытываю очень плохую работу с Cassandra 2.1.5. Я новичок в этом, поэтому буду признателен за любые советы о том, как отлаживать. Вот что моя таблица выглядит следующим образом:Trouble tracing cassandra query

Keyspace: nt_live_october                                             x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
    Read Count: 6                                              x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
    Read Latency: 20837.149166666666 ms.                                         x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
    Write Count: 39799                                             x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
    Write Latency: 0.45696595391844014 ms.                                        x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
    Pending Flushes: 0                                             x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
      Table: nt                                             x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
      SSTable count: 12                                           x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
      Space used (live): 15903191275                                        x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
      Space used (total): 15971044770                                        x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
      Space used by snapshots (total): 0                                       x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
      Off heap memory used (total): 14468424                                      x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
      SSTable Compression Ratio: 0.1308103413354315                                    x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
      Number of keys (estimate): 740                                        x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
      Memtable cell count: 43483                                         x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
      Memtable data size: 9272510                                         x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
      Memtable off heap memory used: 0                                        x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
      Memtable switch count: 17                                         x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
      Local read count: 6                                           x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
      Local read latency: 20837.150 ms                                        x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
      Local write count: 39801                                          x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
      Local write latency: 0.457 ms                                        x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
      Pending flushes: 0                                           x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
      Bloom filter false positives: 0                                        x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
      Bloom filter false ratio: 0.00000                                       x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
      Bloom filter space used: 4832                                        x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
      Bloom filter off heap memory used: 4736                                      x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
      Index summary off heap memory used: 576                                      x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
      Compression metadata off heap memory used: 14463112                                   x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
      Compacted partition minimum bytes: 6867                                      x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
      Compacted partition maximum bytes: 30753941057                                    x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
      Compacted partition mean bytes: 44147544                                      x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
      Average live cells per slice (last five minutes): 0.0                                  x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
      Maximum live cells per slice (last five minutes): 0.0                                  x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
      Average tombstones per slice (last five minutes): 0.0                                  x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
      Maximum tombstones per slice (last five minutes): 0.0

Я выдавшего следующий запрос через cqlsh:

[email protected]> TRACING ON;                                               Tracing is already enabled. Use TRACING OFF to disable.                                      x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
[email protected]> CONSISTENCY;                                            x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
Current consistency level is ONE.                                           x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
[email protected]> select * from nt_live_october.nt where group_id='254358' and epoch >=1444313898 and epoch<=1444348800 LIMIT 1;                    x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
OperationTimedOut: errors={}, last_host=XXX.203 
Statement trace did not complete within 10 seconds

и вот что system_traces.events шоу:

xxx.xxx. xxx.203 | 1281 | Разбор выберите * из nt_live_october.nt где group_id = '254358' \ nand epoch> = 1443916800 и эпоха < = 1444348800 \ nLIMIT 30;
xxx.xxx.xxx.203 | 2604 | Подготовка заявления
xxx.xxx.xxx.203 | 8454 | Выполнение однораздельного запроса для пользователей
xxx.xxx.xxx.203 | 8474 | Приобретение ссылок sstable
xxx.xxx.xxx.203 | 8547 | Слияние памятных надгробных памятников
xxx.xxx.xxx.203 | 8675 | Ключевой кэш для sstable 1
xxx.xxx.xxx.203 | 8685 | Поиск разбиения на начало в файле данных
xxx.xxx.xxx.203 | 9040 | Пропущенные 0/1 нерезкие пересекающиеся sstables, включенные 0 из-за надгробий
xxx.xxx.xxx.203 | 9056 | Объединение данных из memtables и 1 sstables
xxx.xxx.xxx.203 | 9120 | Читать 1 живые и 0 ячейки надгробных камней
xxx.xxx.xxx.203 | 9854 | Read-repair DC_LOCAL
xxx.xxx.xxx.203 | 10033 | Выполнение однораздельного запроса для пользователей
xxx.xxx.xxx.203 | 10046 | Приобретение ссылок sstable
xxx.xxx.xxx.203 | 10105 | Слияние памятных надгробных памятников
xxx.xxx.xxx.203 | 10189 | Ключевой кэш для sstable 1
xxx.xxx.xxx.203 | 10198 | Поиск разбиения на начало в файле данных
xxx.xxx.xxx.203 | 10248 | Пропущенные 0/1 нерезкие пересекающиеся sstables, включенные 0 из-за надгробий
xxx.xxx.xxx.203 | 10261 | Объединение данных из memtables и 1 sstables
xxx.xxx.xxx.203 | 10296 | Читать 1 живые и 0 ячейки надгробных камней
xxx.xxx.xxx.203 | 12511 | Выполнение однораздельного запроса на nt
xxx.xxx.xxx.203 | 12525 | Приобретение ссылок sstable
xxx.xxx.xxx.203 | 12587 | Слияние памятных надгробных памятников
xxx.xxx.xxx.203 | 18067 | спекулировать повтор попыток чтения на /xxx.xxx.xxx.205
xxx.xxx.xxx.203 | 18577 | Отправка сообщения READ в xxx.xxx.xxx.205/xxx.xxx.xxx.205
xxx.xxx.xxx.203 | 25534 | Индекс раздела с 6093 элементами, найденными для sstable 8885
xxx.xxx.xxx.203 | 25571 | Поиск разделов индексированного раздела в файле данных
xxx.xxx.xxx.203 | 34989 | Индекс разделов с 5327 элементами, найденными для sstable 8524
xxx.xxx.xxx.203 | 35022 | Поиск разделов индексированного раздела в файле данных
xxx.xxx.xxx.203 | 36322 | Индекс раздела с 333 элементами, найденными для sstable 8477
xxx.xxx.xxx.203 | 36336 | Поиск разделов индексированного раздела в файле данных
xxx.xxx.xxx.203 | 714242 | Индекс раздела с 299251 элементами для sstable 8541
xxx.xxx.xxx.203 | 714279 | Поиск разделов индексированного раздела в файле данных
xxx.xxx.xxx.203 | 715717 | Индекс раздела с 501 элементами, найденными для sstable 8217
xxx.xxx.xxx.203 | 715745 | Поиск разделов индексированного раздела в файле данных
xxx.xxx.xxx.203 | 716232 | Индекс раздела с 252 элементами, найденными для sstable 8888
xxx.xxx.xxx.203 | 716245 | Поиск разделов индексированного раздела в файле данных
xxx.xxx.xxx.205 | 87 | READ сообщение, полученное от /xxx.xxx.xxx.203
xxx.xxx.xxx.205 | 50427 | Выполнение однораздельного запроса на nt
xxx.xxx.xxx.205 | 50535 | Приобретение ссылок sstable
xxx.xxx.xxx.205 | 50628 | Слияние памятных надгробий
xxx.xxx.xxx.205 | 170441 | Индекс раздела с 35650 элементами, найденными для sstable 6332
xxx.xxx.xxx.203 | 30718026 | Индекс раздела с 199905 элементами для sstable 5958
xxx.xxx.xxx.203 | 30718077 | Поиск разделов индексированного раздела в файле данных
xxx.xxx.xxx.205 | 170499 | Поиск разделов индексированного раздела в файле данных
xxx.xxx.xxx.205 | 248898 | Индекс раздела с 30958 элементами, найденными для sstable 6797
xxx.xxx.xxx.205 | 248962 | Поиск разделов индексированного раздела в файле данных
xxx.xxx.xxx.203 | 67814573 | Тайм-аут чтения: org.apache.cassandra.exceptions.ReadTimeoutException: время ожидания операции - получено только 0 ответов.
xxx.xxx.xxx.203 | 67814675 | Время вышло; получено 0 из 1 ответов

У меня есть 4 узла с коэффициентом репликации 3 (один узел очень светлый, но это не так .203) Данные, которые я пытаюсь прочитать, не очень много - даже если LIMIT 1 не нажимается на удаленный узел, нижний конец интервала должен быть около 3 часов назад (у меня нет эпох за текущее время)

Любые советы о том, как исправить это/что может пойти не так ? Моя версия cassandra - 2.1.9, работает в основном с невыполнением

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

PRIMARY KEY (group_id, epoch, group_name, auto_generated_uuid_field) 
) WITH CLUSTERING ORDER BY (epoch ASC, group_name ASC, auto_generated_uuid_field ASC) 
AND bloom_filter_fp_chance = 0.01 
AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}' 
AND comment = '' 
AND compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'} 
AND compression = {'sstable_compression': 'org.apache.cassandra.io.compress.LZ4Compressor'} 
AND dclocal_read_repair_chance = 0.1 
AND default_time_to_live = 7776000 
AND gc_grace_seconds = 864000 
AND max_index_interval = 2048 
AND memtable_flush_period_in_ms = 0 
AND min_index_interval = 128 
AND read_repair_chance = 0.0 
AND speculative_retry = '99.0PERCENTILE';

___________EDIT_____________ ответить на вопросы ниже:

выхода состояния:

-- Address   Load  Tokens Owns Host ID        Rack                             x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
DN xxx.xxx.xxx.204 15.8 GB 1  ?  32ed196b-f6eb-4e93-b759 r1                              x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
UN xxx.xxx.xxx.205 20.38 GB 1  ?  446d71aa-e9cd-4ca9-a6ac r1                              x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
UN xxx.xxx.xxx.202 1.48 GB 1  ?  2a6670b2-63f2-43be-b672 r1                              x~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
UN xxx.xxx.xxx.203 15.72 GB 1  ?  dd26dfee-82da-454b-8db2 r1

system.log сложнее, как я ВГ еа много лесозаготовок в там ... один подозреваемый, что я вижу, это

WARN [CompactionExecutor:6] 2015-10-08 19:44:16,595 SSTableWriter.java (line 240) Compacting large partition nt_live_october/nt:254358 (230692316 bytes)

, но это просто предупреждение ... вскоре после того, как я вижу

INFO [CompactionExecutor:6] 2015-10-08 19:44:16,642 CompactionTask.java (line 274) Compacted 4 sstables to [/cassandra/data_dir_d/nt_live_october/nt-72813b106b9111e58f1ea1f0942ab78d/nt_live_october-nt-ka-9024,]. 35,733,701 bytes to 30,186,394 (~84% of original) in 34,907ms = 0.824705MB/s. 21 total partitions merged to 18. Partition merge counts were {1:17, 4:1, }

я вижу довольно много из этих пар в журнал ... но не сообщения уровня ERROR. Уплотнение, похоже, идет нормально. Это говорит о том, что это самое большое семейство столбцов, но все сообщения являются уровнем INFO.

источник

2015-10-08 Yana K.

+0

Вы можете проверить System.log обычно в/вар/Журнал/Cassandra/и искать какие-либо предупреждения для больших разделов, большого количества надгробий и узлов придумывают и вниз? Вывод статуса nodetool также может помочь нам. – MarcintheCloud

ответ

2

Во-первых, статус DN узла 204 означает «вниз». Получить его System.log и искать:

  • исключений и журналов уровня ошибок
  • AnormaL GC деятельности (сбор более 200 мс)
  • StatusLogger

Во-вторых, данные плохо распределены среди кластер. Нагрузка 202 составляет всего 1,48 ГБ. Я подозреваю, что у вас есть очень большие разделы, реплицированные на других узлах. Что такое фактор репликации? Какова схема вашего ключа? Вы можете ответить на эти вопросы с командой cqlsh:

DESCRIBE KEYSPACE nt_live_october;

источник

2015-10-09 10:34:33 DineMartine

+0

Спасибо Dine. Да, 204 не работает. Но у меня есть коэффициент репликации 3, поэтому у остальных 3 узлов должно быть много данных. Я бы не ожидал, что один узел снизится настолько, чтобы ухудшить производительность. Я поставлю схему в исходный вопрос –

+0

Нет ERROR, но я вижу GC-паузы около 5K мс, поэтому я буду работать над ними. Спасибо за подсказку. Я буду держать это открытым до тех пор, пока не увижу, что это решает все мои проблемы. –

+2

Я уверен, что вы запрашиваете очень большой раздел. Позволь мне объяснить. В PRIMARY_KEY первым данным столбцом является ключ раздела. Каждая вставка с одним и тем же ключом разделена на один и тот же токен и поэтому записывается в одни и те же реплики. Здесь я вижу, что 3 из ваших узлов содержат больший объем данных, чем последний. Я подозреваю, что вы всегда пишете в nt_live_october с той же partition_key. При запросе этого раздела, если вы не укажете ключи строк, Cassandra попросят манипулировать большой в памяти коллекцией данных, которая будет длинной и вызовет тайм-аут. – DineMartine

Смежные вопросы

 Смежные вопросы