TiDB 写入慢流程排查系列（六）— GC 机制

GangShen · 2021 年1 月 19 日 14:12

TiKV 没有单独的 GC 机制，GC 的触发依赖于 TiDB gc-worker 运行。

TiKV 收到 TiDB 发送的的 GC 命令（包含 SafePoint）后扫描当前 Region 的所有 key，然后对每个 Key 执行 GC 操作，即 SafePoint 之前只保留最后一次提交的数据。缺点是删除也是写入，需等待 compaction 运行后数据才真正删除。另外 GC 过程要占用系统资源，对正常事务的运行产生影响。

TiKV 在 3.0.6 版本开始支持 GC 流控，可通过配置 gc.max-write-bytes-per-sec 限制 GC worker 每秒数据写入量，降低对正常请求的影响，0 为关闭该功能。该配置可通过 tikv-ctl 动态修改

tikv-ctl --host=ip:port modify-tikv-config -m server -n gc.max_write_bytes_per_sec -v 10MB

GangShen · 2021 年1 月 19 日 14:13

第一步：Resolve Locks(清理锁)

Resolve Locks 这一步的任务即对 safe point 之前的锁进行清理。即如果一个锁对应的 Primary 已经提交，那么该锁也应该被提交；反之，则应该回滚。而如果 Primary 仍然是上锁的状态（没有提交也没有回滚），则应当将该事务视为超时失败而回滚。

Resolve Locks 的执行方式是由 GC leader 对所有的 Region 发送请求扫描过期的锁，并对扫到的锁查询 Primary 的状态，再发送请求对其进行提交或回滚。这个过程默认会并行地执行，并发数量默认与 TiKV 节点个数相同。

实际遇到要清理的锁的话，是调用 RocksDB 的 delete 接口，写入一个删除标记。

判断 Resolve Locks 操作的数量可以通过 TiKV-Details → gRPC → gRPC message count 中的 kv_scan_lock 请求数量来判断，kv_scan_lock 请求只会由 GC 导致，resolve_lock 操作可以通过 gRPC message count 中的 kv_resolve_lock 数量判断，但是因为正常查询也会产生 kv_resolve_lock 操作，所以该指标并不完全等同于 GC 产生的 resolve lock 操作。

GangShen · 2021 年1 月 19 日 14:13

第二步：Delete Ranges(删除区间)

在执行 DROP TABLE/INDEX 等操作时，会有大量连续的数据被删除。如果对每个 key 都进行删除操作、再对每个 key 进行 GC 的话，那么执行效率和空间回收速度都可能非常的低下。事实上，这种时候 TiDB 并不会对每个 key 进行删除操作，而是将这些待删除的区间及删除操作的时间戳记录下来。Delete Ranges 会将这些时间戳在 safe point 之前的区间进行快速的物理删除。

判断 Delete Ranges 操作的数量可以通过 TiKV-Details → gRPC → gRPC message count 中的 kv_delete_range 和 unsafe_destroy_range 请求来判断。

GangShen · 2021 年1 月 19 日 14:13

第三步：Do GC(进行 GC 清理)

这一步即删除所有 key 的过期版本。为了保证 safe point 之后的任何时间戳都具有一致的快照，这一步删除 safe point 之前提交的数据，但是会对每个 key 保留 safe point 前的最后一次写入（除非最后一次写入是删除）。

在进行这一步时，TiDB 只需要将 safe point 发送给 PD，即可结束整轮 GC。TiKV 会自行检测到 safe point 发生了更新，会对当前节点上所有作为 Region leader 进行 GC。与此同时，GC leader 可以继续触发下一轮 GC。

Do GC 阶段，实际的操作是 TiKV 去扫描所有的 region ，如果发现 key 的 tso 信息早于 SafePoint 点了，那就调用 RocksDB 的 delete 接口，打一个删除标记。等待后续 Compaction 的时候回收空间。扫描所有 region 这一步有一点优化是，扫描的时候会根据 sst 上的元信息初步判断是否有较多的历史数据，进而来判断是否是可以跳过的。

GangShen · 2021 年1 月 19 日 14:16

GC 相关监控介绍

TiKV-Details → GC → MVCC versions

每个 key 的版本个数，如果 GC 保留时间设置的越长，这个数值可能会越大，查询的时候会需要扫描更多的 MVCC 版本数据后获取到实际数据，影响查询速度。

TiKV-Details → GC → MVCC delete versions

GC 删除掉的每个 key 的版本数量

TiKV-Details → GC → GC tasks

显示 TiKV 的 GC worker 执行的任务。这些任务分为 GC 任务和 UnsafeDestroyRange 任务。以 region 为粒度的。具体的指标有：

total-gc: GC 任务总量。
skipped-gc: 跳过的 GC 任务数量。TiKV 会根据记录在 RocksDB 中的一些元信息来推断一个 Region 是不是并没有太多需要 GC 的数据，如果是的话则跳过该 Region。
failed-gc: GC 任务失败的数量。在 leader 迁移、region 不可用之类的情况下会发生。如果这一指标非常低，则无需在意。
total-unsafe-destroy-range: tikv 实际执行的 UnsafeDestroyRange 任务数量。
failed-unsafe-destory-range: UnsafeDestroyRange 失败的数量。一般不会出现。
gcworker-too-busy: 由于 TiKV 的 GCWorker 队列已满（队列长度为 2），而拒绝掉的请求数量。默认配置下，0 不存在这种情况。但是如果配置成了使用 2.x 版本的旧的 GC 方式，或者对于 2.1.x 版本，当tikv_gc_concurrency 配置较高时，出现这一指标是正常的。
TiKV-Details → GC → GC tasks duration