Cassandra write performance

Question

У нас есть этот кластер Cassandra и хотелось бы узнать, нормальная ли производительность и что мы можем сделать для ее улучшения.

Кластер состоит из 3 узлов, расположенных в одном и том же центре данных общей емкостью 465 ГБ и 2 ГБ кучи на узел. Каждый узел имеет 8 ядер и 8 ГБ или оперативную память. Версия различных компонентов cqlsh 5.0.1 | Cassandra 2.1.11.872 | DSE 4.7.4 | CQL spec 3.2.1 | Native protocol v3

Нагрузка описывается следующим образом:

• пространство ключей используют org.apache.cassandra.locator.SimpleStrategy стратегию размещения и коэффициент репликации 3 (это очень важно для нас)
• Рабочая нагрузка состоит в основном из операций записи в одну таблицу. Схема таблицы выглядит следующим образом: CREATE TABLE aiceweb.records ( process_id timeuuid, partition_key int, collected_at timestamp, received_at timestamp, value text, PRIMARY KEY ((process_id, partition_key), collected_at, received_at) ) WITH CLUSTERING ORDER BY (collected_at DESC, received_at ASC) AND read_repair_chance = 0.0 AND dclocal_read_repair_chance = 0.1 AND gc_grace_seconds = 864000 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 default_time_to_live = 0 AND speculative_retry = '99.0PERCENTILE' AND min_index_interval = 128 AND max_index_interval = 2048;

операция запись приходит с сервером API на основе NodeJS. Используется драйвер Nodejs, предоставляемый Datastax (версия, недавно обновленная с 2.1.1 до 3.2.0). Код, отвечающий за выполнение запроса на запись, будет группировать операции записи на Первичный ключ и дополнительно ограничивать размер запроса до 500 INSERT за запрос. Операция записи выполняется как BATCH. Единственными установленными параметрами являются prepare:true, logged:false.

OpsCenter отражает исторический уровень менее одного запроса за секунду в прошлом году с использованием этой настройки (каждый запрос на запись был битком в 500 операций, направленных на одну и ту же таблицу и тот же раздел). Задержка запроса на запись составляла 1,6 мс для 90% запросов почти целый год, но в последнее время она увеличилась до более чем 2,6 мс для 90% запросов. Os Load была ниже 2.0, а использование диска было менее 5% в большинстве случаев с небольшим количеством пиков на 7%. Среднее использование кучи составляло 1,3 ГБ в течение всего года с пиками на 1,6 ГБ, хотя в настоящий момент этот пик растет в течение последнего месяца.

Проблема с этой настройкой заключается в том, что производительность API ухудшалась весь год. В настоящее время операция BATCH может принимать от 300 мс до более чем 12 секунд (что приводит к таймауту работы). В некоторых случаях драйвер NodeJS сообщает все драйверы Cassandra, даже когда OpsCenter сообщает всем узлам живым и здоровым.

Уплотнительная Статистика всегда 0 показывает на каждом узле и nodetool tpstats показывает что-то вроде:

Pool Name     Active Pending  Completed Blocked All time blocked 
CounterMutationStage    0   0   10554   0     0 
ReadStage       0   0   687567   0     0 
RequestResponseStage    0   0   767898   0     0 
MutationStage      0   0   393407   0     0 
ReadRepairStage     0   0   411   0     0 
GossipStage      0   0  1314414   0     0 
CacheCleanupExecutor    0   0    48   0     0 
MigrationStage     0   0    0   0     0 
ValidationExecutor    0   0   126   0     0 
Sampler       0   0    0   0     0 
MemtableReclaimMemory    0   0   497   0     0 
InternalResponseStage    0   0   126   0     0 
AntiEntropyStage     0   0   630   0     0 
MiscStage       0   0    0   0     0 
CommitLogArchiver     0   0    0   0     0 
MemtableFlushWriter    0   0   485   0     0 
PendingRangeCalculator   0   0    4   0     0 
MemtablePostFlush     0   0   7879   0     0 
CompactionExecutor    0   0   263599   0     0 
AntiEntropySessions    0   0    3   0     0 
HintedHandoff      0   0    8   0     0 

Message type   Dropped 
RANGE_SLICE     0 
READ_REPAIR     0 
PAGED_RANGE     0 
BINARY      0 
READ       0 
MUTATION      0 
_TRACE      0 
REQUEST_RESPONSE    0 
COUNTER_MUTATION    0 

Любая помощь или предложение с этой проблемой будет глубоко признателен. Не стесняйтесь запрашивать любую другую информацию, необходимую для ее анализа.

С наилучшими пожеланиями

Answer 1

Вы остаетесь с таким же количеством запросов, или нагрузка растет?

Похоже, что сервер перегружен (возможно, сеть).

Answer 2

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

Существует пример того, как включить трассировку запросов и retrive выхода через nodejs примеров драйверов извлечение-запрос-trace.js (можно найти на https://github.com/datastax/nodejs-driver)