扩缩容建议 - ClickHouse Documentation

简介

数据库资源的自动扩缩容需要谨慎权衡：扩容过慢可能带来性能下降风险，而缩容过于激进则可能引发持续震荡。 ClickHouse Cloud 通过将双窗口推荐框架与目标跟踪型 CPU 推荐系统相结合，在保持生产环境数据库所需稳定性的同时，实现了更快的缩容、尽量减少扩缩容震荡，并显著降低了可变工作负载的基础设施成本。

基于 CPU 的扩缩容

CPU 扩缩容基于目标跟踪，它会精确计算将利用率维持在目标水平所需的 CPU 配额。只有当当前 CPU 利用率超出设定区间时，才会触发扩缩容操作：

参数	值	含义
目标利用率	53%	ClickHouse 计划维持的利用率水平
高水位	75%	当 CPU 超过此阈值时触发扩容
低水位	37.5%	当 CPU 低于此阈值时触发缩容

推荐器会根据历史使用情况评估 CPU 利用率，并使用以下公式确定建议的 CPU 大小：

recommended_cpu = max_cpu_usage / target_utilization

如果 CPU 利用率处于已分配容量的 37.5%–75% 之间，则不会执行任何扩缩容操作。超出该区间时，推荐器会计算出将利用率恢复到 53% 所需的精确容量，并据此对服务进行扩缩容。

示例

一个分配了 4 vCPU 的服务，使用量突增至 3.8 vCPU (利用率约为 95%) ，超过了 75% 的高水位阈值。推荐器会计算：3.8 / 0.53 ≈ 7.2 vCPU，并向上取整到下一个可用规格 (8 vCPU) 。当负载回落、使用量降至 37.5% (1.5 vCPU) 以下时，推荐器会按比例缩容。

基于内存的推荐

ClickHouse Cloud 会根据您的服务实际使用情况自动推荐内存大小。推荐器会分析回溯窗口内的使用情况，并预留额外余量，以应对突发峰值并防止内存不足 (OOM) 错误。推荐器会考察三个信号：

查询内存：查询执行期间的峰值内存占用
常驻内存：进程整体的峰值内存占用
OOM 事件：查询或副本最近是否出现过内存不足

如何计算余量

对于查询内存和常驻内存，增加多少余量取决于你的使用情况有多可预测：

使用稳定 (波动较小) ：1.25 倍系数——余量更高，因为使用情况较为稳定，不太可能突然飙升
使用波动较大 (变化明显) ：1.1 倍系数——余量较低，以避免对本就波动较大的工作负载过度预配

如果检测到 OOM 事件，推荐器会采用更激进的 1.5 倍系数，以确保服务有足够的内存恢复运行。

最终建议

系统会取所有信号中的最高值：

desired_memory = max(
  query_memory × skew_multiplier,
  resident_memory × skew_multiplier,
  resident_memory × 1.5,   // 如果检测到查询 OOM
  rss_at_crash × 1.5       // 如果检测到 pod（容器组）OOM
)

双窗口推荐器

ClickHouse Cloud 不使用单一窗口，而是采用两个时间范围不同的回溯窗口：

小窗口 (3 小时)：捕捉近期使用模式，支持更快缩容
大窗口 (30 小时)：确保我们能够根据较长回溯窗口内观察到的最大使用量，一步完成扩容，而不是经过多次逐步扩容。这一点至关重要，因为扩缩容需要时间，而且会使本地缓存失效；因此，一步扩容更安全。

每个窗口都会基于内存和 CPU 分析独立生成一个推荐结果。然后，系统会根据每个窗口给出的扩缩容方向合并这些推荐结果，如下图所示：如需深入了解该推荐器的设计决策，请参阅 “ClickHouse 的更智能自动扩缩容：双窗口方法 ”

​简介

​基于 CPU 的扩缩容

​示例

​基于内存的推荐

​如何计算余量

​最终建议

​双窗口推荐器

简介

基于 CPU 的扩缩容

示例

基于内存的推荐

如何计算余量

最终建议

双窗口推荐器