Таймауты частого чтения и записи Cassandra

Я изменил всю кодовую базу с Thrift на CQL, используя datastax java driver 1.0.1 и cassandra 1.2.6..

с бережливостью я получал частые тайм-ауты с самого начала, я не мог продолжить ... Принятие CQL, таблиц, разработанных в соответствии с этим, я добился успеха и меньше тайм-аутов ....

Благодаря этому я смог вставить огромные данные, которые не работали экономно ... Но после этапа папка с данными около 3,5 ГБ. Я получаю частые исключения из-за тайм-аута записи. даже я снова делаю тот же предыдущий рабочий вариант использования, который теперь также вызывает исключение тайм-аута. ЕГО СЛУЧАЙНАЯ СЛУЧАЙНАЯ РАБОТА СНОВА НЕ РАБОТАЕТ ДАЖЕ ПОСЛЕ СВЕЖЕЙ НАСТРОЙКИ.

ЖУРНАЛ СЕРВЕРА CASSADNRA

это режим частичного журнала сервера cassandra DEBUG, тогда я получил ошибку:

http://pastebin.com/rW0B4MD0

Исключение клиента:

Caused by: com.datastax.driver.core.exceptions.WriteTimeoutException: Cassandra timeout during write query at consistency ONE (1 replica were required but only 0 acknowledged the write)
    at com.datastax.driver.core.exceptions.WriteTimeoutException.copy(WriteTimeoutException.java:54)
    at com.datastax.driver.core.ResultSetFuture.extractCauseFromExecutionException(ResultSetFuture.java:214)
    at com.datastax.driver.core.ResultSetFuture.getUninterruptibly(ResultSetFuture.java:169)
    at com.datastax.driver.core.Session.execute(Session.java:107)
    at com.datastax.driver.core.Session.execute(Session.java:76)

Инфраструктура: машина 16 ГБ с кучей 8 ГБ, выделенной для cassandra, процессор i7 .. Я использую Cassandra с ОДНИМ узлом с этим yaml, настроенным на тайм-аут, все остальное по умолчанию:

  • read_request_timeout_in_ms: 30000
  • range_request_timeout_in_ms: 30000
  • write_request_timeout_in_ms: 30000
  • truncate_request_timeout_in_ms: 60000
  • request_timeout_in_ms: 30000

СЛУЧАЙ ИСПОЛЬЗОВАНИЯ: я использую вариант использования, в котором комбинации (терминология моего проекта) хранятся в кассандре .... В настоящее время тестируется хранение 250 000 комбинаций со 100 параллельными потоками .. каждый поток хранит одну комбинацию ... реальный случае мне нужно поддерживать десятки миллионов, но для этого потребуется другое оборудование и многоузловой кластер ...

Сохранение ОДНОЙ комбинации занимает около 2 секунд и включает в себя:

  • 527 запросов INSERT INTO
  • 506 запросов UPDATE
  • 954 запроса SELECT

100 параллельных потоков параллельно хранят 100 комбинаций.

Я обнаружил случайное поведение WRITE TIMEOUTS, иногда оно работает до 200 000, затем выбрасывает таймауты и иногда не работают даже для 10k комбинаций. СЛУЧАЙНОЕ ПОВЕДЕНИЕ.


cassandra timeout datastax-java-driver
person user2572801    schedule 07.08.2013    source источник
comment
Прекратите регистрацию в DEBUG и посмотрите, что Statuslogger говорит в INFO.   -  person jbellis    schedule 08.08.2013

Ответы (4)


arrow_upward
2
arrow_downward

Я обнаружил, что во время некоторых операций чтения cassandra-stress, если я установлю слишком высокую скорость потоков, я получу эту ошибку CL. Подумайте о том, чтобы во время теста снизить количество потоков до чего-то доступного для вашего пула, чтобы поддерживать его, чтобы превзойти

  • read_request_timeout_in_ms

На мой взгляд, изменение этого в cassandra.yaml не всегда является хорошей идеей. Учитывайте аппаратные ресурсы, с которыми работают ваши машины.

для яйца:

cassandra-stress read n=100000 cl=ONE -rate threads=200 -node N1

выдаст мне ошибку, а

cassandra-stress read n=100000 cl=ONE -rate threads=121 -node N1

сделает работу без сбоев.

Надеюсь, это поможет вам подняться, ребята.

P.S. когда вы выполняете тесты чтения, попробуйте распределить чтение даже по данным с помощью '-pop dist = UNIFORM (1..1000000)' или сколько хотите.

person Mr'Black    schedule 29.05.2016

arrow_upward
1
arrow_downward

Просто потратил некоторое время, чтобы прочитать мою конфигурацию yaml узлов dev cassandra, потому что у меня была аналогичная проблема. Моя система застопорилась и выдает тайм-аут, когда я пытался загрузить около 3 миллиардов хэшей sha2 на свой узел разработки, имея всего 600 МБ ОЗУ;)

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

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

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

Похоже, что параметры Cassandra по умолчанию предназначены для тяжелых машин с большим количеством ядер в многоузловом кластере, который может распределять нагрузку. Чтобы запустить его в локальной среде разработки, прикрутите его. Его среда разработки, а не система жизни, найдите время, чтобы выпить кофе или два;)

Надеюсь, что это поможет научиться думать правильно

person Rene M.    schedule 07.08.2013
comment
спасибо большое, попробую в этом направлении, просто чтобы проверить, работает ли это ... В моем случае 1-2 раза он работал при огромной нагрузке, но большую часть времени он не работает даже при меньшей нагрузке, чем отработанный ... вот и все почему я запутался, если это сработало, то почему бы не снова, если в системе нет изменений ... - person user2572801; 07.08.2013

arrow_upward
0
arrow_downward

Из вашего фрагмента журнала для Cassandra было предоставлено только 4 ГБ кучи, и она заполняется. Скорее всего, это ваша проблема:

DEBUG [ScheduledTasks:1] 2013-08-07 15:08:09,434 GCInspector.java (line 121) GC for ParNew: 155 ms for 6 collections, 3230372760 used; max is 4277534720

max - 4277534720 == куча 4 ГБ. Вам следует зайти в свой cassandra-env.sh и явно установить максимальную кучу и новые размеры кучи. Для описанного вами узла максимальная куча 8 ГБ и новая куча 800 МБ, вероятно, являются хорошей отправной точкой.

person Zanson    schedule 10.08.2013

arrow_upward
0
arrow_downward

Я также столкнулся с этой проблемой: «Тайм-аут Cassandra во время запроса записи с согласованностью LOCAL_ONE (0 реплик) подтвердил необходимость записи более 1» "Тайм-аут Cassandra во время запроса read с согласованностью LOCAL_ONE (0 реплик) подтвердили необходимость записи более 1 ». Я справился с этим, изменив параметр в cassandra.yaml. Выполняя поиск "timeout" в cassandra.yaml, вы найдете read_request_timeout_in_ms: 5000 write_request_timeout_in_ms: 2000 Увеличьте число и перезапустите "cassandra -f". Моя проблема была решена. Надеюсь, это вам тоже поможет!

person David    schedule 08.03.2016