tidb 集群 p95 上升的问题记录

公司 tidb 集群 p95 突然上升。排查监控发现 tikv 同时间有大量 gc worker 开始运行。同时集群的 safepoint 向前跳了一大截。之前的 safepoint 大概是三天以前。

这里就带来了以下几个问题。

1. safepoint 为什么会有这么大的 lag。
2. safepoint 为什么会突然向前推进。
3. safepoint 是如何影响 gc ，进而影响整个集群响应时间的。

safepoint 是什么

• safepoint 是一个时间点。
• commit_ts 早于 safepoint 的多余版本数据都可以被清理掉。

tikv 是基于 rocksdb 的分布式 kv 存储，基于 mvcc 实现 snapshot 级别的隔离。每个数据都会保留多个版本。简单来说，snapshot 级别的隔离要求 start_ts 开始的事务 txn_1，一定可以读到 commit_ts < start_ts 的数据，并且读不到 commit_ts > start_ts 的数据。同时，每隔固定时间就要对多余的版本数据进行清理，否则随着数据的更新，存储空间和读写效率都会下降。清理的同时，还要保证不能破坏 snapshot isolation。tidb 中目前是这么做的：

1. 假设当前 safepoint 为 s1。
2. 10min 之后，计算一个新的 safepoint，记为 s2。注意此时不能直接把 safepoint 设为 s2，这样会导致 commit_ts < s2 的多余版本数据可能会被清理掉。如果当前有一个事务开始时间为 start_ts1 的事务 txn1 正在运行，数据 tuple1 有两个版本 commit_ts1 和 commit_ts2，其中 commit_ts1 < start_ts1< commit_ts2 < s2。 如果此时 safepoint 被设为 s2。则 tuple1 commit_ts1 版本就可能会被清理掉，txn1 就读不到版本为 commit_ts1 的 tuple1 了。破坏了 snapshot isolation。
3. 获取当前正在运行的所有事务中最小的 start_ts，记为 start_ts_min。
4. 设置 safepoint 为 min(start_ts_min, s2)。

safepoint 突然跃进的原因

有一个 ticdc 的数据同步任务在三天前卡住没有处理，ticdc 可能是通过 start_ts_min 来控制 safepoint 不再向前推进的，只是猜测，具体实现细节没有细看。然后 DBA 同学在今天清理掉了这个任务，导致 safepoint 向前跳了一大截。

p95 上升的原因

三天时间，集群中积累了大量可以被清理掉的多版本数据。safepoint 向前推进之后，tikv 瞬间启动了大量 gc worker ，由于没有进行限速，这些 gc worker 占用了很多的磁盘 io 和内存资源。导致 cache miss，同时读磁盘的时延也有所上升，最主要的原因还是 cache miss 增多。

解决方式

通过 tikv-ctl 命令对 gc woker 进行限流，实时生效。

也可以限制 gc concurrency，需要重启生效。