# [Known Issues] sorter 文件过多导致 TiCDC 同步延迟

## Key Words

sorter 文件过多（too many open files）, TiCDC 流控, TiCDC 同步延迟

## Description

问题背景：

1. TiCDC 滚动重启后同步延迟持续增加，TiCDC Puller 停止处理 Change log（Puller output events/s 为 0），持续 1.5 小时后恢复。
2. 上游 TiDB 写入 QPS 2000 左右，SQL 都是单行 update/insert，大部分语句是自动提交，没有执行 DDL。
3. TiCDC 日志报错 \[WARN] \[backend_pool.go:125] \["unified sorter: getting system memory usage failed"] \[error="open /proc/meminfo: too many open files"]。
4. TiCDC 集群有3个节点，每个节点配置：CPU 6 cores, Mem 5GB, Disk iops 2300, Disk bandwith 150MB/s。

相关 issue：

[https://github.com/pingcap/tiflow/issues/2698](https://github.com/pingcap/tiflow/issues/2698)
[https://github.com/pingcap/tiflow/issues/2793](https://github.com/pingcap/tiflow/issues/2793)

## Root Cause

Unified Sorter 打开过多 sorter 文件导致 Sorter 性能低下，性能问题触发 gRPC 流控，TiKV 和 TiCDC 之间的连接（EventFeed gRPC stream）被熔断，TiCDC 无法收到 resolved ts 等事件，导致 checkpoint ts 不能正常推进。

## Diagnostic Steps

1. sorter 打开的磁盘文件过多：监控 Open FD count 显示达到 open file limit 上限，TiCDC 日志也有 too many open files 报错。

    ![know-issue-ticdc-store-latency1](/images/TiCDC/know-issue-ticdc-store-latency1.png)

2. TiCDC sorter 卡住触发 gRPC 流控：监控 CDC memory 显示 sink memory 上涨到 sink-memory-quota 512MiB

    ![know-issue-ticdc-store-latency2.png](/images/TiCDC/know-issue-ticdc-store-latency2.png)

3. Eventfeed gRPC 连接熔断：连接断开时会注销 captured region

    ![know-issue-ticdc-store-latency3.png](/images/TiCDC/know-issue-ticdc-store-latency3.png)

## Resolution

升级 TiCDC 到 v6.0 以上版本，默认开启 db sorter，避免 sorter 的 too many open files 问题。

## Workaround

1. 调大流控触发阈值 per-table-memory-quota（默认 10M），可以缓解 TiCDC 延迟程度。
2. 为 Unified Sorter 准备高性能的 SSD 磁盘，避免使用延迟或吞吐有瓶颈的存储设备，如机械硬盘，性能一般的云盘等。
3. 如果希望关闭 Unified Sorter，请手动将 changefeed 的 sort-engine 设为 memory。

## Affected Versions

v6.0 以下版本，开启 Unified Sorter 功能