Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Azure Управляемый экземпляр для Apache Cassandra — это полностью управляемая служба для чистых кластеров Apache Cassandra с открытым кодом. Служба также позволяет переопределить конфигурации в зависимости от конкретных потребностей каждой рабочей нагрузки. Эта функция обеспечивает максимальную гибкость и контроль, где это необходимо. В этой статье содержатся советы по оптимизации производительности.
Оптимальная настройка и настройка
Коэффициент репликации, количество дисков, количество узлов и уровни продуктов
Azure поддерживает три зоны доступности в большинстве регионов. Управляемый экземпляр Azure для Apache Cassandra сопоставляет зоны доступности с стойками. Рекомендуется выбрать ключ раздела с высокой кардинальностью, чтобы избежать горячих разделов. Для оптимального уровня надежности и отказоустойчивости настоятельно рекомендуется настроить коэффициент репликации 3. Мы также рекомендуем указать число узлов как кратное коэффициента репликации. Например, используйте 3, 6, 9 и т. д.
Azure использует RAID 0 по количеству подготовленных дисков. Чтобы получить оптимальное количество операций ввода-вывода в секунду (IOPS), проверьте максимальное IOPS для выбранного уровня продукта вместе с IOPS диска P30. Например, уровень Standard_DS14_v2 продукта поддерживает 51200 операций ввода-вывода в секунду без кэширования. Один диск P30 имеет базовую производительность в 5 000 операций ввода-вывода в секунду. Четыре диска приводят к 20 000 операций ввода-вывода в секунду, что значительно ниже ограничений компьютера.
Настоятельно рекомендуется использовать широкий тест производительности рабочей нагрузки на уровне продукта и количестве дисков. Тестирование особенно важно для уровней продуктов с только восемью ядрами. Наше исследование показывает, что восемь ядер ЦП работают только для наименее требовательных рабочих нагрузок. Для правильной работы большинства рабочих нагрузок требуется не менее 16 ядер.
Аналитические и транзакционные рабочие нагрузки
Как правило, для рабочих нагрузок транзакций требуется центр обработки данных, оптимизированный для низкой задержки. Аналитические рабочие нагрузки часто используют более сложные запросы, которые требуют больше времени для выполнения. В большинстве случаев требуется использовать отдельные центры обработки данных:
- Система оптимизирована для низкой задержки.
- Один оптимизирован для аналитических рабочих нагрузок.
Оптимизация под аналитические рабочие нагрузки
Рекомендуется применить следующие cassandra.yaml параметры для аналитических рабочих нагрузок. Дополнительные сведения о применении этих параметров см. в разделе "Обновление конфигурации Cassandra".
Время ожидания
| Ценность | По умолчанию Cassandra MI | Рекомендация для аналитической рабочей нагрузки |
|---|---|---|
read_request_timeout_in_ms |
5 000 | 10 000 |
range_request_timeout_in_ms |
10 000 | 20 000 |
counter_write_request_timeout_in_ms |
5 000 | 10 000 |
cas_contention_timeout_in_ms |
1 000 | 2 000 |
truncate_request_timeout_in_ms |
60 000 | 120 000 |
slow_query_log_timeout_in_ms |
500 | 1 000 |
roles_validity_in_ms |
2 000 | 120 000 |
permissions_validity_in_ms |
2 000 | 120 000 |
Кэши
| Ценность | По умолчанию Cassandra MI | Рекомендация для аналитической рабочей нагрузки |
|---|---|---|
file_cache_size_in_mb |
2,048 | 6144 |
Дополнительные рекомендации
| Ценность | По умолчанию Cassandra MI | Рекомендация для аналитической рабочей нагрузки |
|---|---|---|
commitlog_total_space_in_mb |
8,192 | 16,384 |
column_index_size_in_kb |
64 | 16 |
compaction_throughput_mb_per_sec |
128 | 256 |
Параметры клиентов
Мы рекомендуем увеличить время ожидания драйвера клиента Cassandra в соответствии с настройками времени ожидания, примененными на сервере.
Оптимизация для низкой задержки
Наши параметры по умолчанию уже подходят для рабочих нагрузок с низкой задержкой. Чтобы обеспечить оптимальную производительность для конечных задержек, мы настоятельно рекомендуем использовать клиентский драйвер, поддерживающий спекулятивное выполнение и соответствующим образом настроить клиент. Для драйвера Java версии 4 демонстрация показывает, как работает этот процесс и как включить политику в этом примере.
Мониторинг узких мест производительности
Производительность ЦП
Как и каждая система базы данных, Cassandra работает лучше, если загрузка ЦП составляет около 50 % и никогда не получает выше 80 %. Чтобы просмотреть метрики ЦП, откройте вкладку "Метрики" на портале Azure в разделе "Мониторинг".
Для реалистичного представления ЦП добавьте фильтр и используйте Usage kind=usage_idle для разделения свойства. Если это значение меньше 20%, примените разделение для получения использования по всем типам использования.
Если ЦП постоянно превышает 80% для большинства узлов, база данных становится перегруженной, что проявляется в многочисленных тайм-аутах клиентов. В этом сценарии рекомендуется выполнить следующие действия:
- Увеличьте вертикально масштаб вычислительных ресурсов продукта, добавив больше ядер процессора, особенно если их количество всего 8 или меньше.
- Горизонтальное масштабирование путем добавления дополнительных узлов. Как упоминалось ранее, число узлов должно быть кратным фактору репликации.
Если у ЦПУ высокая загрузка только для нескольких узлов, но низкая для других, это указывает на горячую партицию. Для этого сценария требуется дальнейшее исследование.
Изменение уровня продуктов поддерживается с помощью портала Azure, Azure CLI и развертывания шаблона Azure Resource Manager (шаблона ARM). Вы можете развернуть или изменить шаблон ARM и заменить уровень продукта одним из следующих значений:
Standard_E8s_v4Standard_E16s_v4Standard_E20s_v4Standard_E32s_v4Standard_DS13_v2Standard_DS14_v2Standard_D8s_v4Standard_D16s_v4Standard_D32s_v4Standard_L8s_v3Standard_L16s_v3Standard_L32s_v3Standard_L8as_v3Standard_L16as_v3Standard_L32as_v3
В настоящее время мы не поддерживаем переход между семействами продуктов. Например, если в настоящее время у вас есть Standard_DS13_v2 и вы хотите перейти на более крупный продукт, например Standard_DS14_v2, такой параметр недоступен. Откройте запрос в службу поддержки, чтобы запросить обновление до более высокого продукта.
Производительность дисков
Служба работает на управляемых дисках Azure P30, которые позволяют burst IOPS. Тщательный мониторинг требуется, когда речь идет о узких местах производительности, связанных с диском. В этом случае важно проверить метрики IOPS (операций ввода-вывода в секунду).
Если метрики показывают одну или все следующие характеристики, может потребоваться увеличить масштаб:
- Ваши метрики постоянно выше или равны базовым IOPS. Не забудьте умножить 5000 операций ввода-вывода в секунду на количество дисков на каждый узел, чтобы получить итоговое число.
- Ваши показатели постоянно выше или равны максимально допустимому количеству IOPS для уровня продукта при выполнении операций записи.
- Уровень продукта поддерживает кэшированное хранилище (кэширование с записью через), и это число меньше, чем количество операций ввода-вывода в секунду, поддерживаемое управляемыми дисками. Это значение является верхним пределом операций ввода-вывода в секунду (IOPS).
Если вы видите увеличение операций ввода-вывода в секунду только на нескольких узлах, возможно, у вас есть горячий раздел, и необходимо просмотреть данные для потенциального перекоса.
Если ваши показатели IOPS ниже, чем поддерживает уровень продукта, но больше или равны значению IOPS диска, выполните следующие действия:
- Добавьте дополнительные узлы для увеличения масштаба центров обработки данных.
Если ваши IOPS достигают верхнего предела, который поддерживает ваш уровень тарифа, можете:
- Измените уровень продукта на более высокий, который поддерживает больше операций ввода-вывода в секунду (IOPS).
- Добавьте дополнительные узлы для увеличения масштаба центров обработки данных.
Дополнительные сведения см. в разделе "Производительность виртуальных машин и дисков".
Производительность сети
Как правило, производительность сети достаточна. При частой потоковой передаче данных, например, частом горизонтальном масштабировании или уменьшении масштаба, а также при значительных перемещениях входящих и исходящих данных, могут возникнуть проблемы с производительностью. Возможно, потребуется оценить производительность сети уровня продуктов. Например, уровень Standard_DS14_v2 продукта поддерживает 12 000 МБ/с. Сравните это значение с входом/выходом байтов в показателях метрик.
Если вы видите сеть с повышенными привилегиями только для нескольких узлов, возможно, у вас есть горячая секция. Просмотрите шаблоны распределения данных и доступа для потенциального отклонения.
- Вертикальное масштабирование до другого уровня продукта путем поддержки большего объема операций ввода-вывода сети.
- Горизонтальное масштабирование кластера путем добавления дополнительных узлов.
Слишком много подключенных клиентов
Планирование и подготовка развертываний для поддержки максимального количества параллельных запросов, необходимых для требуемой задержки приложения. Для конкретного развертывания введение большей нагрузки в систему выше минимального порогового значения увеличивает общую задержку. Отслеживайте количество подключенных клиентов, чтобы убедиться, что эта ситуация не превышает допустимые ограничения.
Место на диске
В большинстве случаев достаточно места на диске. Развертывания по умолчанию оптимизированы для IOPS, что приводит к низкому уровню использования диска. Тем не менее, рекомендуется иногда просматривать метрики пространства на диске. Cassandra накапливает множество дисков, а затем уменьшает их при срабатывании сжатия. Важно проверить использование дисков в течение более длительных периодов, чтобы установить тенденции, например, когда сжатие не может восстановить пространство.
Примечание.
Чтобы гарантировать наличие свободного пространства для сжатия, поддерживайте использование диска на уровне около 50%.
Если вы видите это поведение только для нескольких узлов, возможно, у вас есть горячая секция. Просмотрите шаблоны распределения данных и доступа для потенциального отклонения.
- Добавьте больше дисков, но учитывайте ограничения IOPS, установленные вашим уровнем тарифного плана.
- Горизонтальное масштабирование кластера.
Память JVM
Наша формула по умолчанию назначает половину памяти виртуальной машины виртуальной машине Java (JVM) с верхним ограничением в 31 ГБ. В большинстве случаев этот подход является хорошим балансом между производительностью и памятью. Некоторые рабочие нагрузки, особенно те, которые часто считывают данные из нескольких разделов или осуществляют сканирование диапазона, могут испытывать проблемы с памятью.
В большинстве случаев память эффективно освобождается сборщиком мусора Java. Если центральный процессор (ЦП) часто работает выше 80%, для сборщика мусора остается недостаточно циклов процессора. Решите проблемы с производительностью ЦПУ перед проверкой проблем с памятью.
Если ЦП наведите указатель мыши ниже 70% и сборка мусора не может освободить память, может потребоваться больше памяти JVM. Если вы находитесь на уровне продукта с ограниченным объемом памяти, может потребоваться больше памяти JVM. В большинстве случаев необходимо пересмотреть ваши запросы и настройки клиента, а также сократить fetch_size наряду с выбранными параметрами в limit запросе CQL.
Если требуется больше памяти, можно:
- Вертикальное масштабирование до уровня продукта с большим объемом доступной памяти.
Надгробий
Мы запускаем восстановление каждые семь дней с помощью reaper, который удаляет строки, время жизни (TTL) которых истекло. Эти строки называются могилами. Некоторые нагрузки удаляют данные чаще и отображают предупреждения, например Read 96 live rows and 5035 tombstone cells for query SELECT ...; token <token> (see tombstone_warn_threshold) в журналах Cassandra. Некоторые ошибки указывают на то, что запрос не может быть выполнен из-за чрезмерного количества могильных записей.
Краткосрочная мера, если запросы не выполняются, — увеличить tombstone_failure_threshold параметр в конфигурации Cassandra с 100 000 по умолчанию до более высокого значения.
Мы также рекомендуем просмотреть TTL в ключевом пространстве и ежедневно запускать восстановление, чтобы очистить больше могильных камней. Если TTL короткие (например, менее двух дней), а потоки данных поступают и удаляются быстро, мы рекомендуем пересмотреть стратегию сжатия и отдать предпочтение Leveled Compaction Strategy. В некоторых случаях такие действия могут указывать на необходимость проверки модели данных.
Предупреждения пакетной службы
В CassandraLogs и потенциально связанных сбоях может возникнуть следующее предупреждение:
Batch for [<table>] is of size 6.740KiB, exceeding specified threshold of 5.000KiB by 1.740KiB.
Проверьте свои запросы, чтобы оставаться ниже рекомендованного размера партии. В редких случаях и в качестве краткосрочного решения увеличьте значение batch_size_fail_threshold_in_kb в конфигурации Cassandra с 50 по умолчанию до более высокого значения.
Предупреждение о большой секции
В CassandraLogs может появиться следующее предупреждение:
Writing large partition <table> (105.426MiB) to sstable <file>
Это сообщение указывает на проблему в модели данных. Дополнительные сведения см. в этой статье stack Overflow. Эта проблема может привести к серьезным проблемам с производительностью и должна быть устранена.
Специализированные оптимизации
Сжатие
Cassandra позволяет выбрать соответствующий алгоритм сжатия при создании таблицы. Значение по умолчанию — LZ4, отличное для пропускной способности и ЦП, но потребляет больше места на диске. Использование Zstandard (Cassandra 4.0 и выше) экономит около 12% места с минимальной нагрузкой на ЦП.
Оптимизация пространства памяти memtable
По умолчанию используется четверть кучи JVM для memtable_heap_space в cassandra.yaml файле. Для приложений, ориентированных на запись, или на уровнях продуктов с небольшим объемом памяти эта проблема может привести к частым сбросам данных и фрагментации sstables, что требует более серьезной компактизации. Увеличение до минимум 4048 может быть целесообразным. Этот подход требует тщательного бенчмаркинга, чтобы убедиться, что другие операции, например чтение, не затронуты.