Высокая нагрузка на узлы Cassandra

По какой-то причине я испытываю высокую нагрузку на свои узлы Cassandra. Вот некоторая информация, чтобы получить картину.

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

  • Я делаю снимки одного из своих пространств ключей, содержащих около 300-400 МБ данных, каждые 4 часа и удаляю те, что старше 7 дней, все настроено в OpsCenter.

  • Кластер работает на чередующихся дисках в Microsoft Azure.

  • Узлы работают на 2 ядрах с 3,5 ГБ ОЗУ, я прекрасно понимаю, что это ниже рекомендуемого оборудования, но это не должно быть причиной высокой нагрузки, я пробовал работать на 4 ядрах с 7 ГБ ОЗУ и не увидел разницы

Я уверен, что, вероятно, есть целый ряд вещей, которые могут вызвать высокую нагрузку, но я думаю, что что-то более вероятно, чем что-то еще.

введите здесь описание изображения

Редактировать

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


cassandra datastax-enterprise opscenter
person parek    schedule 19.01.2015    source источник

Ответы (1)


arrow_upward
5
arrow_downward

Вы можете настроить службу восстановления, добавив раздел [repair_service] в ваш файл opscenterd.conf.

Основными рычагами настройки являются:

max_parallel_repairs = 0

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

min_repair_time = 5

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

snapshot_override

Опять же, если у вас не слишком много данных и служба восстановления завершается слишком быстро, вы будете создавать слишком много моментальных снимков (по умолчанию служба восстановления делает снимок перед каждым восстановлением). Если ваш каталог моментальных снимков заполняется очень быстро, вы можете отключить эту функцию до тех пор, пока не настроите службу на однократный запуск (используйте повышения min_repair_time drop parallel_repairs).

Примечание. Смысл услуги по ремонту состоит в том, чтобы разделить дорогостоящий и ресурсоемкий процесс ремонта на более мелкие задачи. Это означает, что вы всегда можете увеличить общую загрузку процессора на 5 % или 10 %. вместо того, чтобы вызывать скачки и влиять на вашу рабочую нагрузку во время регулярных ремонтных работ.

Подробная информация о расширенной настройке

person phact    schedule 19.01.2015
comment
Черт, в этом столько смысла. Это, конечно, причина, по которой было создано так много снимков. Превосходно. - person parek; 19.01.2015
comment
Рад быть полезным :) - person phact; 19.01.2015