TiCDC性能优化实战：从5k到60k QPS的突破

TiCDC性能优化实战：从5k到60k QPS的突破

引用

CSDN

等

7

来源

1.

https://blog.csdn.net/weixin_42073629/article/details/120108929

2.

https://tidb.net/blog/tag/performance-tuning

3.

https://cn.pingcap.com/article/post/16590.html

4.

https://cn.pingcap.com/article/post/18168.html

5.

https://cn.pingcap.com/blog/upgrading-is-the-best-tuning/

6.

https://www.bookstack.cn/read/tidb-7.5-zh/6efa96e07635075f.md?wd=dm

7.

https://cn.pingcap.com/article/post/17188.html

在现代分布式数据库系统中，数据同步的效率和稳定性至关重要。作为TiDB生态系统中的核心组件，TiCDC（TiDB Data Change Capture）负责数据变更的捕获和同步，其性能直接影响到整个系统的运行效率。本文将深入探讨TiCDC的性能优化技巧，通过调整关键参数和监控指标，实现从5k到60k QPS的显著性能提升。

在开始优化之前，我们需要了解几个关键参数的作用：

1. per-table-memory-quota：控制每个表在Sorter阶段可使用的最大内存。增加该值可以提升排序效率，但过大会消耗更多系统资源。建议根据业务写入量和集群资源合理设置，避免节点OOM风险。

2. worker-count：Sink阶段的并发数，影响数据写入下游的速度。需要通过测试找到最佳值，在保证性能的同时避免资源过度消耗。

3. max-batch-size 和 max-batch-memory：限制发送到Kafka消息的最大行数和内存使用，平衡处理速度与资源占用。根据网络状况和下游处理能力进行调整。

4. 超时相关参数：如 dial-timeout、read-timeout 和 write-timeout，需根据网络环境优化。

5. 其他重要参数：

   • enable-old-value：开启后会记录变更前的数据，对性能有影响，可根据需求启用。
   • mounter-worker-num 和 sink-worker-num：分别控制Mounter和Sink阶段的并发数，默认为8和16，可通过调整优化性能。

业务背景

某线上集群频繁出现cdc_resolvedts_high_delay告警，甚至出现ErrGCTTLExceeded异常，导致增量备份任务失败。这些问题严重影响了集群备份数据的可用性和安全性，亟需优化解决。

问题分析

通过分析，我们发现同步延迟可能由以下几个原因造成：

1. 组件间网络延迟过大
2. 上游写入量过大或下游写入速度过慢
3. TiCDC工具本身性能瓶颈

解决方案

针对v5.3.0版本的TiCDC，我们重点优化了Sorter算子内存参数和Sink同步并发：

• 将per-table-memory-quota设置为800MB
• 将同步任务worker-count设置为1250

经过测试验证，实时同步的QPS从5k优化到60k，提升12倍以上。同步到TiDB的稳定QPS约为53k，同步到S3的稳定QPS约为10k。

1. 监控指标：

   • Changefeed checkpoint lag：反映从上游数据变更到下游完成同步的时间差，正常情况下应小于10秒。
   • Changefeed resolved ts lag：表示TiCDC内部处理进度与上游的差距，过高可能意味着瓶颈。
   • QPS：关注同步任务的吞吐量，如达到60k QPS则表明性能较优。

2. 注意事项：

   • 调整per-table-memory-quota时需谨慎，过大会导致节点OOM。
   • 如果TiCDC同步流有延迟，需要尽快处理，避免重启时对节点资源造成冲击。
   • 在满负载追数据同步场景，建议使用上述参数组合以保证性能和稳定性。

通过合理调整关键参数和持续监控，我们可以显著提升TiCDC的性能表现。但需要注意的是，每个场景的具体参数需要根据业务特点和集群资源重新测试验证。同时，及时响应延迟告警，避免长时间延迟导致的资源消耗问题。希望本文能为读者提供有价值的参考，帮助大家更好地优化TiCDC性能。