Как получить надежные времена вставки в Кассандре? - PullRequest
5 голосов
/ 20 марта 2012

В настоящее время я тестирую Cassandra с 3 узлами, используя CassandraSharp.Моя главная проблема - больше задержек, чем пропускной способности, поэтому после небольшой настройки GC вот мои цифры (на 100 000K вставок, монопоток):

  • Iter / sec: 1600
  • Среднее значение: 600 мкс
  • 95 цент: 600 мкс
  • 99 цент: 5000 мкс
  • Макс: 50 000 мкс

Моя проблема в том, что однажды внекоторое время я получаю «плохую» задержку (50 мс), моя цель - иметь постоянную задержку, даже за счет более высокого среднего значения.

Я считаю, что это вызвано GC, и яинтересно, можно ли этого избежать.

(Как примечание: рекомендуется ли отправлять большое количество вставок на один узел и разрешать его обрабатывать, или я должен «балансировать нагрузку» в клиенте?)

Ответы [ 3 ]

2 голосов
/ 21 марта 2012

50 мс - в пределах нормы для сборки мусора молодого поколения.Вы можете включить ведение журнала GC в cassandra-env.sh, раскомментировав соответствующие строки внизу, чтобы убедиться, что это проблема.

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

Если коллекции молодого поколения действительно коррелируют с более высокими задержками, вы можете уменьшить попытку сделать молодое поколение меньшим (также настроенным в cassandra-env.sh), по потенциальной стоимости торговой задержки для пропускной способности.

1 голос
/ 20 марта 2012

Не думаю, что вы сможете время от времени избавляться от проблемы плохой задержки.Скорее всего, это будет тот GC, о котором вы упомянули, или когда он выполняет сброс на диск из Memtables.

Неужели плохая вставка 50 мс действительно проблема?Cassandra поддерживает пакетные мутаторы, которые позволяют ставить в очередь операции вставки в одном длинном мутаторе, а затем выполнять пакетные вставки позднее, так что ваш основной поток не должен блокироваться синхронной вставкой, которая может занять больше времени, чеможидается.Я не использовал CassandarSharp, поэтому не знаю, предоставляет ли он эту функциональность.

Кроме того, распределение нагрузки между узлами cassandra немного улучшит время импорта, но помните, что за кулисами происходит то, что происходит за кулисами.узел, в который вы осуществляете импорт, передаст его правильному узлу для хранения (таким образом, узел, который вы предоставляете, действует как прокси-сервер), поэтому я не представляю большого улучшения в общем случае.Это поможет вам, если по какой-то причине этот узел начинает делать другие вещи, и его производительность страдает.

0 голосов
/ 20 марта 2012

Если вас интересует надежное время вставки, возможно, вы захотите проверить распределение Cunandra в Acunu, которое обеспечивает в 100 раз более стабильную задержку для вставок: Cassandra при большой нагрузке записи (обратите внимание, в частности, на второе изображение).

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