Рекомендации по оптимальной производительности
Azure Управляемый экземпляр для Apache Cassandra — это полностью управляемая служба для чистых кластеров Apache Cassandra с открытым кодом. Служба также позволяет переопределить конфигурации в зависимости от конкретных потребностей каждой рабочей нагрузки, что позволяет обеспечить максимальную гибкость и контроль при необходимости. В этой статье содержатся советы по оптимизации производительности.
Оптимальная настройка и настройка
Коэффициент репликации, количество дисков, количество узлов и номеров SKU
Так как поддержка Azure три зоны доступности в большинстве регионов, а Cassandra Управляемый экземпляр сопоставляет зоны доступности с стойкими, рекомендуется выбрать ключ секции с высокой карта inality, чтобы избежать горячих секций. Для оптимального уровня надежности и отказоустойчивости настоятельно рекомендуется настроить коэффициент реплика от 3. Мы также рекомендуем указать несколько факторов реплика tion в качестве количества узлов, например 3, 6, 9 и т. д.
Мы используем RAID 0 по количеству подготовленных дисков. Таким образом, чтобы получить оптимальные операции ввода-вывода в секунду, необходимо проверка максимальное количество операций ввода-вывода в секунду на номерЕ SKU, выбранного вместе с операцией ввода-вывода в секунду диска P30. Например, Standard_DS14_v2 SKU поддерживает 51 200 некичированных операций ввода-вывода в секунду, а один диск P30 имеет базовую производительность 5000 операций ввода-вывода в секунду. Таким образом, четыре диска приведет к 20 000 операций ввода-вывода в секунду, что значительно ниже ограничений компьютера.
Настоятельно рекомендуется использовать широкий тест производительности рабочей нагрузки по номеру SKU и количеству дисков. Тестирование особенно важно в случае SKU с только восемью ядрами. Наше исследование показывает, что восемь основных ЦП работают только для наименее требовательных рабочих нагрузок, и большинство рабочих нагрузок требуют не менее 16 ядер для выполнения.
Аналитические и транзакционные рабочие нагрузки
Как правило, для рабочих нагрузок транзакций требуется центр обработки данных, оптимизированный для низкой задержки, а аналитические рабочие нагрузки часто используют более сложные запросы, что занимает больше времени для выполнения. В большинстве случаев требуется отдельные центры обработки данных:
- Один оптимизирован для низкой задержки
- Один оптимизированный для аналитических рабочих нагрузок
Оптимизация для аналитических рабочих нагрузок
Мы рекомендуем клиентам применять следующие cassandra.yaml параметры для аналитических рабочих нагрузок (см . здесь , как применить).
Время ожидания
| Value | По умолчанию 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 |
Кэши
| Value | По умолчанию Cassandra MI | Рекомендация для аналитической рабочей нагрузки |
|---|---|---|
| file_cache_size_in_mb | 2,048 | 6144 |
Дополнительные рекомендации
| Value | По умолчанию 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 %. На вкладке "Метрики метрик" на портале мониторинга можно просмотреть метрики ЦП:
Если ЦП постоянно превышает 80 % для большинства узлов, база данных становится перегруженной манифестированием в нескольких времени ожидания клиента. В этом сценарии рекомендуется выполнить следующие действия:
- Вертикальное масштабирование до SKU с большим количеством ядер ЦП (особенно если ядра имеют только 8 или меньше).
- горизонтально масштабируемый путем добавления дополнительных узлов (как упоминание ранее число узлов должно быть кратным фактором реплика tion).
Если ЦП достаточно высок для нескольких узлов, но низкий для других, он указывает на горячую секцию и нуждается в дальнейшем изучении.
Примечание.
Изменение номера SKU поддерживается с помощью портала Azure, azure CLI и развертывания шаблона ARM. Вы можете развернуть и изменить шаблон ARM и заменить номер SKU одним из следующих элементов.
- Standard_E8s_v4
- Standard_E16s_v4
- Standard_E20s_v4
- Standard_E32s_v4
- Standard_DS13_v2
- Standard_DS14_v2
- Standard_D8s_v4
- Standard_D16s_v4
- Standard_D32s_v4
- Standard L8s_v3
- Standard L16s_v3
- Standard_L32s_v3
- Standard_L8as_v3
- Standard_L16as_v3
- Standard_L32as_v3
Обратите внимание, что в настоящее время мы не поддерживаем переход между семействами SKU. Например, если в настоящее время вы обладаете Standard_DS13_v2 и заинтересованы в обновлении до более крупного номера SKU, например Standard_DS14_v2, этот параметр недоступен. Однако вы можете открыть запрос в службу поддержки, чтобы запросить обновление до более высокого номера SKU.
Производительность дисков
Служба выполняется на управляемых дисках Azure P30, которые позволяют выполнять операции ввода-вывода в секунду. Тщательный мониторинг требуется, когда речь идет о узких местах производительности диска. В этом случае важно проверить метрики операций ввода-вывода в секунду:
Если метрики показывают одну или все перечисленные ниже характеристики, она может указать, что необходимо увеличить масштаб.
- Постоянно выше или равно базовому числу операций ввода-вывода в секунду (не забудьте умножить 5000 операций ввода-вывода в секунду на число дисков на узел).
- Постоянно выше или равно максимальному значению операций ввода-вывода в секунду, разрешенного для SKU для операций записи.
- Номер SKU поддерживает кэшированное хранилище (кэш через запись) и это число меньше, чем число операций ввода-вывода в секунду с управляемых дисков (это будет верхним ограничением для операций ввода-вывода в секунду).
Если для нескольких узлов отображается только повышенный уровень операций ввода-вывода в секунду, возможно, у вас есть горячая секция и требуется просмотреть данные для потенциального отклонения.
Если число операций ввода-вывода в секунду ниже, чем то, что поддерживается выбранным номером SKU, но выше или равно дисковому объему операций ввода-вывода в секунду, можно выполнить следующие действия:
- Добавьте дополнительные диски для повышения производительности. Увеличение дисков требует создания варианта поддержки.
- Увеличение масштаба центров обработки данных путем добавления дополнительных узлов.
Если ваш номер SKU поддерживает максимальное количество операций ввода-вывода в секунду, вы можете:
- масштабируйте до другого номера SKU, поддерживающего больше операций ввода-вывода в секунду.
- Увеличение масштаба центров обработки данных путем добавления дополнительных узлов.
Дополнительные сведения см. в статье о производительности виртуальных машин и дисков.
Производительность сети
В большинстве случаев производительность сети достаточна. Тем не менее, если вы часто потоковые данные (например, частое горизонтальное масштабирование или уменьшение масштаба) или есть огромные перемещения данных входящего/исходящего трафика, это может стать проблемой. Возможно, потребуется оценить производительность сети номера SKU. Например, Standard_DS14_v2 номер SKU поддерживает 12 000 МБ/с, сравните это с байтами в метриках:
Если вы видите только сеть с повышенными привилегиями для нескольких узлов, возможно, у вас есть горячая секция и необходимо проверить распределение данных и (или) шаблоны доступа для потенциального отклонения.
- Вертикальное масштабирование до другого номера SKU, поддерживающего больше сетевых операций ввода-вывода.
- Горизонтальное масштабирование кластера путем добавления дополнительных узлов.
Слишком много подключенных клиентов
Развертывания должны быть запланированы и подготовлены для поддержки максимального количества параллельных запросов, необходимых для требуемой задержки приложения. Для данного развертывания введение большей нагрузки в систему выше минимального порогового значения увеличивает общую задержку. Отслеживайте количество подключенных клиентов, чтобы убедиться, что это не превышает допустимые ограничения.
Место на диске
В большинстве случаев достаточно места на диске, так как развертывания по умолчанию оптимизированы для операций ввода-вывода в секунду, что приводит к низкому использованию диска. Тем не менее, мы советуем иногда просматривать метрики пространства на диске. Cassandra накапливает много дисков, а затем уменьшает его при активации сжатия. Поэтому важно проверить использование дисков в течение более длительных периодов, чтобы установить тенденции, такие как сжатие, не удается восстановить пространство.
Примечание.
Чтобы обеспечить доступное пространство для сжатия, использование дисков должно храниться примерно до 50 %.
Если вы видите это поведение только для нескольких узлов, возможно, у вас есть горячая секция и необходимо проверить распределение данных и (или) шаблоны доступа для потенциального отклонения.
- добавление дополнительных дисков, но учитывайте ограничения операций ввода-вывода в секунду, введенные номером SKU.
- горизонтальное масштабирование кластера
Память JVM
Наша формула по умолчанию назначает половину памяти виртуальной машины JVM с верхним ограничением в 31 ГБ, что в большинстве случаев является хорошим балансом между производительностью и памятью. Некоторые рабочие нагрузки, особенно с частыми перекрестными считываниями или проверками диапазона, могут быть вызваны проблемами с памятью.
В большинстве случаев память эффективно удаляется сборщиком мусора Java, но особенно если ЦП часто превышает 80 % не хватает циклов ЦП для сборщика мусора слева. Поэтому любые проблемы с производительностью ЦП должны решаться перед проблемами с памятью.
Если ЦП наведите указатель мыши ниже 70%, а сборка мусора не может восстановить память, может потребоваться больше памяти JVM. Это особенно касается SKU с ограниченным объемом памяти. В большинстве случаев необходимо просмотреть запросы и параметры клиента и уменьшить fetch_size их вместе с тем, что выбрано в limit запросе CQL.
Если вам действительно нужна дополнительная память, вы можете:
- Отправьте запрос для нас, чтобы увеличить параметры памяти JVM для вас
- Вертикальное масштабирование до номера SKU с большим объемом памяти
Надгробий
Мы выполняем восстановление каждые семь дней с отжимом, который удаляет строки, срок жизни которых истек (называется "tombstone"). Некоторые рабочие нагрузки имеют более частые удаления и видят предупреждения, такие как 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 в пространстве ключей и потенциально выполнять ремонт ежедневно, чтобы очистить больше камней. Если TTLs коротки, например менее двух дней, и потоки данных и удаляются быстро, рекомендуется просмотреть стратегию сжатия и предпочесть 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>
Это означает проблему в модели данных. Ниже приведена статья о переполнении стека, которая подробно описывается. Это может привести к серьезным проблемам с производительностью и необходимо устранить.
Специализированные оптимизации
Сжатие
Cassandra позволяет выбрать соответствующий алгоритм сжатия при создании таблицы (см . сжатие) Значение по умолчанию — LZ4, которое отлично подходит для пропускной способности и ЦП, но потребляет больше места на диске. Использование Zstd (Cassandra 4.0 и up) экономит около 12% пространства с минимальными затратами на ЦП.
Оптимизация пространства кучи с возможностью объединения
По умолчанию для memtable_heap_space в cassandra.yaml используется куча JVM 1/4. Для ориентированных на запись приложений и (или) на SKU с небольшой памятью это может привести к частым очисткам и фрагментированным меткам, таким образом, требуя большего сжатия. В таких случаях это может быть полезно по крайней мере до 4048, но требует тщательного тестирования, чтобы убедиться, что другие операции (например, операции чтения) не затрагиваются.
Следующие шаги
В этой статье мы изложили некоторые рекомендации по оптимальной производительности. Теперь можно приступить к работе с кластером: