你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure Managed Instance for Apache Cassandra 是针对纯开源 Apache Cassandra 群集的完全托管服务。 该服务还允许重写配置，具体取决于每个工作负载的特定需求。 此功能可根据需要实现最大的灵活性和控制。 本文提供有关如何优化性能的提示。
最佳设置和部署
复制因子、磁盘数、节点数和产品层
Azure 在大多数区域支持 三个 可用区。 适用于 Apache Cassandra 的 Azure 托管实例将可用性区域映射到机架。 建议选择具有高基数的分区键以避免热分区。 为了获得最佳可靠性和容错级别，我们强烈建议配置复制因子 3。 我们还建议将复制因子的倍数指定为节点数。 例如，使用 3、6、9 等。
Azure 对预配的磁盘数使用 RAID 0。 若要获得每秒最佳的输入/输出操作（IOPS），请检查您所选择的产品层的最大 IOPS 以及 P30 磁盘的 IOPS。 例如， Standard_DS14_v2 产品层支持 51,200 个未缓存的 IOPS。 单个 P30 磁盘的基性能为 5,000 IOPS。 四个磁盘提供了 20,000 IOPS，远远低于机器的性能上限。
我们强烈建议针对产品层和磁盘数量对工作负荷进行广泛的基准测试。 基准测试对于只有八个核心的产品层尤其重要。 我们的研究表明，八核 CPU 仅适用于最不苛刻的工作负载。 大多数工作负荷至少需要 16 个核心才能正常运行。
分析工作负荷与事务工作负荷
事务工作负荷通常需要针对低延迟进行优化的数据中心。 分析工作负荷通常使用更复杂的查询，这需要更长的时间才能运行。 在大多数情况下，需要使用独立的数据中心：
- 一个针对低延迟进行优化。
- 针对分析负载进行优化的系统。
针对分析工作负荷进行优化
建议对分析工作负荷应用以下 cassandra.yaml 设置。 有关如何应用这些设置的详细信息，请参阅 Update Cassandra 配置。
超时
| 价值 | Cassandra MI 默认值 | 对分析型工作负载的建议 |
|---|---|---|
read_request_timeout_in_ms |
5,000 | 1万 |
range_request_timeout_in_ms |
1万 | 20,000 |
counter_write_request_timeout_in_ms |
5,000 | 1万 |
cas_contention_timeout_in_ms |
1,000 | 二千 |
truncate_request_timeout_in_ms |
60,000 | 120,000 |
slow_query_log_timeout_in_ms |
500 | 1,000 |
roles_validity_in_ms |
二千 | 120,000 |
permissions_validity_in_ms |
二千 | 120,000 |
缓存
| 价值 | Cassandra MI 默认值 | 对分析型工作负载的建议 |
|---|---|---|
file_cache_size_in_mb |
2,048 | 6,144 |
更多建议
| 价值 | 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 V4 驱动程序，演示演示演示了此过程的工作原理以及如何 在此示例中启用策略。
监视性能瓶颈
CPU 性能
与每个数据库系统一样，如果 CPU 利用率约为 50%，并且始终不会超过 80%，那么 Cassandra 效果最佳。 若要查看 CPU 指标，请在 Azure 门户的 “监视 ”部分下打开“ 指标 ”选项卡。
为了获得真实的 CPU 视图，请添加筛选器，并使用 Usage kind=usage_idle 来拆分属性。 如果此值低于 20%，则应用拆分以按各种使用类型获取使用情况。
如果大多数节点的 CPU 永久超过 80%，则数据库将过载，这在多个客户端超时中会出现。 在此方案中，我们建议你执行以下作：
- 纵向扩展到具有更多 CPU 核心的产品层，尤其是在核心数仅为 8 或更少时。
- 通过添加更多节点来水平缩放。 如前所述，节点数应为复制因子的倍数。
如果 CPU 在仅有几个节点上高，但在其他节点上较低，则表示热分区。 此方案需要进一步调查。
使用 Azure 门户、Azure CLI 和 Azure 资源管理器模板（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 管理磁盘上，支持 突增 IOPS。 当涉及到与磁盘相关的性能瓶颈时，需要仔细监视。 在这种情况下，请务必查看 IOPS 指标。
如果指标显示以下一个或全部特征，可能需要纵向扩展：
- 指标始终高于或等于基本 IOPS。 请记住，将 5,000 IOPS 乘以每个节点的磁盘数来获取该数字。
- 您的性能指标始终高于或等于产品层允许的写入最大IOPS。
- 您的产品层级支持缓存存储（直写缓存），并且此数字小于托管磁盘中的 IOPS。 此值是读取 IOPS 的上限。
如果只看到几个节点的 IOPS 数增加，那么你可能有热分区，并需要查看数据是否存在潜在的倾斜。
如果 IOPS 低于产品层支持的 IOPS，但高于或等于磁盘 IOPS，请执行以下操作：
- 添加更多磁盘来提高性能。 您需要提出支持请求来增加磁盘容量。
- 添加更多节点以 纵向扩展数据中心。
如果 IOPS 达到产品层支持的上限，则可以：
- 纵向扩展到支持更多 IOPS 的不同产品层。
- 添加更多节点以 纵向扩展数据中心。
有关详细信息，请参阅 虚拟机和磁盘性能。
网络性能
通常，网络性能已足够。 如果你经常流式处理数据（录入频繁的水平纵向扩展/纵向缩减），或者存在大量的入口/出口数据移动，此性能可能会成为一个问题。 可能需要评估产品层的网络性能。 例如， Standard_DS14_v2 产品层支持 12,000 Mb/秒。 将此值与指标中的字节输入/输出进行比较。
如果看到只为几个节点提升的网络，则可能具有热分区。 查看数据分布和访问模式，了解潜在的偏差。
- 通过支持更多网络 I/O，垂直扩展到不同的产品层。
- 通过添加更多节点水平纵向扩展群集。
连接的客户端数太多
规划和实施部署，以支持应用程序达到所需延迟时所需的最大并行请求数量。 对于特定部署，将更多负载引入到高于最低阈值的系统会增加总体延迟。 监视连接的客户端数，以确保这种情况不会超过可容忍的限制。
磁盘空间
在大多数情况下，有足够的磁盘空间。 默认部署针对 IOPS 进行优化，这会导致磁盘利用率较低。 不过，我们建议偶尔查看磁盘空间指标。 Cassandra 会累积大量磁盘，然后在触发压缩时减少它们。 请务必在较长时间内查看磁盘使用情况，以确定趋势，例如压缩无法收回空间时。
注意
为了确保压缩的可用空间，请将磁盘利用率保持在大约 50%。
如果仅在几个节点上看到这种行为，则可能存在热分区。 查看数据分布和访问模式，了解潜在的偏差。
- 添加更多磁盘，但请注意产品层施加的 IOPS 限制。
- 水平纵向扩展群集。
JVM 内存
默认公式将虚拟机内存的一半分配给 Java 虚拟机（JVM），上限为 31 GB。 在大多数情况下，此方法在性能和内存之间是很好的平衡。 某些工作负荷（尤其是具有频繁跨分区读取或范围扫描的工作负荷）可能会受到内存挑战。
在大多数情况下，Java 垃圾回收器可以有效地回收内存。 如果 CPU 通常超过 80%，则垃圾回收器剩余的 CPU 周期不足。 在检查任何内存问题之前解决 CPU 性能问题。
如果 CPU 悬停在 70% 以下，垃圾回收无法回收内存，则可能需要更多 JVM 内存。 如果处于具有有限内存的产品层上，可能需要更多 JVM 内存。 在大多数情况下，需要查看查询和客户端设置，并减少 fetch_size 以及你在 Cassandra 查询语言 (CQL) 查询中的 limit 中选择的内容。
如果需要更多内存，可以：
- 提交工单以增加 JVM 内存设置。
- 垂直缩放到具有更多可用内存的产品层。
逻辑删除
我们每七天使用清理工具进行一次修复，移除那些生存时间 (TTL) 过期的行。 这些行称为 墓碑。 某些工作负荷会更频繁地删除，并在 Cassandra 日志中显示警告 Read 96 live rows and 5035 tombstone cells for query SELECT ...; token <token> (see tombstone_warn_threshold) 。 一些错误表示由于过多的墓碑而无法完成查询。
如果未满足查询，则短期缓解措施是将 tombstone_failure_thresholdCassandra 配置 中的值从默认 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.
审查你的查询，确保它们在建议的批量大小之下。 在极少数情况下，作为短期缓解措施，可以在 Cassandra 配置中将 batch_size_fail_threshold_in_kb 从默认值 50 增加到更高的值。
大型分区警告
CassandraLogs 中可能会遇到以下警告：
Writing large partition <table> (105.426MiB) to sstable <file>
此消息指示数据模型中存在问题。 有关详细信息，请参阅此 Stack Overflow 文章。 此问题可能会导致严重的性能问题，必须解决。
专用优化
压缩
Cassandra 允许在创建表时选择适当的压缩算法。 默认值为 LZ4，非常适合吞吐量和 CPU，但在磁盘上占用更多空间。 使用 Zstandard （Cassandra 4.0 及更新）可以节省大约 12 个% 空间，且 CPU 开销最小。
优化内存表堆空间
默认情况下，会在文件中为memtable_heap_spacecassandra.yaml分配 JVM 堆的四分之一。 对于面向写入的应用程序或具有少量内存的产品层，此问题可能会导致频繁的刷新和碎片化的 sstables，这需要更多的压缩。 增加到至少 4,048 可能会更好。 此方法需要仔细进行基准测试，以确保其他操作（例如，读操作）不会受到影响。