上图是否cdc 任务内部排序慢，如何调优

[wluckdog (lili)]

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】 v6.1.0

【遇到的问题：问题现象及影响】

schema storage gc progress 代表什么意思，这个参数有一个表一直没有动，卡在哪里，是不是也有延迟问题，如何调优

这种是不是说明cdc任务排序慢，如何调优

[Lucien-卢西恩 (路西恩)]

目前 TiCDC 是不是有一些 DDL 操作还在执行，另外内存占用应该会很高。另外如果是 sorter event 比较慢，要关注一下是不是大事务，通过 TiDB log 得 “BIG_TXN” 关键字和 TiDB “Trsaction Write Size Bytes” 的大小情况，再看看 TiCDC的监控 Sink write 监控。
如果确实是大事务，建议将这部分数据通过其他的备份方式同步到下游，比如使用 BR 或者 Lighting 的方式。

[wluckdog (lili)]

是有一些大事务的字样，但是量不是很多，可能是同步了一张宽表，300多个字段，日志上出现BIG_TXN每个tidb节点30-80条不等，这种情况下应该怎么调优cdc节点呢，目前是做增量同步，所以BR和lighting无法使用

同一个表，建立两个测试任务同步到不同kafka，cdc端抽取延迟也不同，这是为什么呢

[asddongmen (dongmen)]

Q1. 这种情况下应该怎么调优cdc节点呢？

1. 如果你是用的 TiCDC 是 6.1.0 版本，可以尝试一下使用 6.1.2 版本。6.1.2 对大事务有相应的优化。
2. 300 多个字段的大单表，6.1.0 版本的 cdc 编码速度较慢，确实会导致同步速度跟不上的情况。可以考虑把那一张大单表单独使用一个 changefeed 进行同步，因为它可能拖慢了其它表的同步进度，并且也可以加快对该表消息的编码速度。

Q2. 同一个表，建立两个测试任务同步到不同kafka，cdc端抽取延迟也不同，这是为什么呢？

1. 可能是不同 kafka 的网络速度不一样，可以观测一下写到不同 kafka 的 changfeed 的 sink write duration percentile 指标是不是相差较大。

最后，6.5.0 和 6.1.3 的 cdc 会对宽表的同步有针对性的优化，到时候你可以尝试使用。