Время ожидания Cassandra истекло при запросе ключа, содержащего более 10 000 строк, даже после предоставления тайм-аута в 10 секунд

Я использую DataStax Community v 2.1.2-1 (AMI v 2.5) с предустановленными настройками по умолчанию. И у меня есть таблица:

CREATE TABLE notificationstore.note (
  user_id text,
  real_time timestamp,
  insert_time timeuuid,
  read boolean,
  PRIMARY KEY (user_id, real_time, insert_time))
WITH CLUSTERING ORDER BY (real_time DESC, insert_time ASC)
AND bloom_filter_fp_chance = 0.01
AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}
AND **default_time_to_live** = 20160

Другие конфигурации:

У меня 2 узла. на m3.large с 1 x 32 (SSD). Я сталкиваюсь с проблемой тайм-аутов, даже если в этой конкретной таблице согласованность установлена ​​​​на ОДИН.

  1. Я увеличил объем кучи до 3 ГБ [размер оперативной памяти 8 ГБ]
  2. Я увеличил время ожидания чтения до 10 секунд.
    select count (*) from note where user_id = 'xxx' limit 2; // errors={}, last_host=127.0.0.1.

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

Данных в базе очень мало.
Также эта проблема возникает не сразу после вставки. Происходит это через некоторое время (более 6 часов)

Спасибо.


amazon-ec2 cassandra datastax ttl cql3
person mehnaazm    schedule 07.12.2014    source источник
comment
обратитесь к этому вопросу... 24899220/rpc-timeout-in-cassandra/   -  person Helping Hand..    schedule 07.12.2014
comment
Я уже установил тайм-аут на 10 секунд и перезапустил свою кассандру на обоих узлах. не повезло. даже если бы это было так, я думаю, что запрос занимает слишком много времени, 10 секунд, учитывая, что моя таблица невелика.   -  person mehnaazm    schedule 07.12.2014
comment
@mehnaazm Я думаю, что это та же проблема, что и мой ответ здесь: stackoverflow.com/questions/27376784/. Должен ли я скопировать этот ответ здесь для полноты?   -  person BrianC    schedule 10.12.2014
comment
@BrianC, да, это решило проблему   -  person mehnaazm    schedule 11.12.2014

Ответы (1)


arrow_upward
2
arrow_downward

[Копирую мой ответ отсюда, потому что это та же среда/проблема: amazon ec2 - Время ожидания Cassandra истекло из-за истечения TTL.]

Вы столкнулись с проблемой, когда количество надгробий (удаленных значений) превышает пороговое значение, а затем истекает время ожидания.

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

cqlsh> tracing on;
cqlsh> select count(*) from test.simple;

 activity                                                                        | timestamp    | source       | source_elapsed
---------------------------------------------------------------------------------+--------------+--------------+----------------
...snip...
 Scanned over 100000 tombstones; query aborted (see tombstone_failure_threshold) | 23:36:59,324 |  172.31.0.85 |         123932
                                                    Scanned 1 rows and matched 1 | 23:36:59,325 |  172.31.0.85 |         124575
                           Timed out; received 0 of 1 responses for range 2 of 4 | 23:37:09,200 | 172.31.13.33 |       10002216

Вы как бы сталкиваетесь с анти-паттерном для Cassandra, где данные хранятся в течение короткого времени, прежде чем будут удалены. Есть несколько вариантов, как лучше справиться с этим, включая пересмотр вашей модели данных, если это необходимо. Вот некоторые ресурсы:

Для вашего примера проблемы я попытался снизить настройку gc_grace_seconds до 300 (5 минут). Это приводит к тому, что надгробия очищаются чаще, чем 10 дней по умолчанию, но это может быть или не быть подходящим в зависимости от вашего приложения. Прочтите о последствиях удаления, и вы сможете при необходимости настроить его для своего приложения.

person BrianC    schedule 11.12.2014