TiKV单个节点负载突然高，持续10min后恢复，期间请求一直被卡死

[dba-kit (张天师)]

为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【 TiDB 使用环境】
TiDB v5.1.0，Aliyun ECS自建SSD集群，包含2台tidb，3台tipd，3台tikv。主要存的是用户资产信息，用了聚簇索引，主键是『账户 + 交易账号』，在数据分布上已经被打散了。使用场景分两类：

• 批量写入：每10min检查基金是否有净值更新，如果有更新，会触发批量更新持有对应基金的交易账号信息
• OLTP查询：查询都是以「账户」为纬度查询。

【现象】 业务和数据库现象
业务使用场景：每天都会清空前一天的数据，也就是每天对应的表都会从空表增加。在19点后会启动Spark Job，接收基金净值更新的kafka Topic，每10min更新一次TiDB中的多个表，在写入时候负载比较高。
现象：在19:20更新资产时，三台TiKV负载都比较高(分别为5/7/9，虽然有些不均匀但还可以接受)，但是批量更新JOB结束后，有一台TiKV节点负载开始飙升(16C64G机器，用了13C，剩下两个节点只用了1、2个核)，期间落到该节点的查询都一直被卡死，没有响应。

【问题排查】 当前遇到的问题
根据tikv.log日志信息，当时每分钟的slow-query日志输出达到1k多甚至2k：

通过详细看故障阶段的日志，剔除掉正常的日志报错，发现有两种异常的日志：

  173 KvService response batch commands fail
 1747 Coprocessor task terminated due to exceeding the deadline

看监控的话，在故障节点多个指标的Duration都比正常时大了很多。
不过TiKV-Detail ==> RocksDB-kv ==> Number of Snapshots指标，正常时候应该是0的，故障节点达到了400多，不清楚是否有关联

---

现在怀疑这些都是因为表迅速扩大，导致Region热点出现，但是业务在这种场景下已经跑了有一个月了，没有出现过问题，现在也是正常的。希望能找出当时故障的最终原因，达到避免的目的。

[xfworld (魔幻之翼)]

@dba-kit

每天都会清空前一天的数据

这个数据是采用什么方式清空的？是 标准的delete，还是drop？

[dba-kit (张天师)]

RENAME + CREATE

[xfworld (魔幻之翼)]

rename 后的表，怎么处理了呢？ 就挂着？

[xfworld (魔幻之翼)]

慢查询需要持续优化，或者限制最大运行时间，不过 回收机制也需要等待，那么慢查询所占用的资源，不会及时释放，这个一定要注意！

[dba-kit (张天师)]

额，貌似关注点有偏差。我再陈述一下使用背景吧。

1. 我们已经对表结构和查询SQL做过优化了：用的聚簇索引做主键(用户 + 基金代码)，没有创建其他索引。OLTP是按照「用户」来查询，所以查询SQL本身是没有问题，正常只会按照主键扫描，大概率是落到1个region上，请求也会被打散。
2. 按照这种业务模式，已经跑了一个多月了，一直没有出现问题。是前天晚上突然有「单个TiKV节点」负载特别高，过了10min又自动恢复了。现在不知道触发的原因是什么，这个才是我提问的重点。

[xfworld (魔幻之翼)]

大量的数据 GC，慢查询， 等等都会导致这个负载高的问题

要一点点的排查…

LSMTree 的特性，决定了Delete 释放的时间，所以我在问你，旧的数据是怎么清理的

[dba-kit (张天师)]

至于我提到的「每天会清理旧表数据」，是想说明：这个表是从0开始增长的，所以前期会遇到「写热点」的问题，某个TiKV节点负载在批量写入时候负载高，这个是可以理解的。难以解释的是，为什么这个节点会在批量写入结束后，持续出现负载高的情况。
至于处理方式，现在每天下午15-16点之间的，会将旧表RENAME成备份表，然后用CREATE LIKE方式创建新表。之后在晚上19点开始，接收基金的净值更新消息，批量更新数据。OLTP查询是全天都会有，晚上20-22点是高峰期。出问题时是19:20 ~ 19:30之间，这个时候查询请求很少的

[dba-kit (张天师)]

感觉是「写入」引起的，而不是查询

[xfworld (魔幻之翼)]

写入的排查思路：

1. 排除热点问题
2. 排除硬件性能问题

可以参考下指南：
https://asktug.com/t/topic/95104

TiDB 写入慢流程排查系列（四）— TiKV Server 写入流程

3. Scheduler gRPC 把对应的请求发送给 tikv scheduler 线程池来执行写操作的不同具体动作，如：prewrite、commit 等。在具体执行这些动作时，会先拿到一个 Snapshot，然后根据这个请求的具体类型执行一些具体逻辑，比如读取锁信息，然后将最终要写入的数据写入 Raftstore。Scheduler duration 等于 latch-wait durat…

【SOP 系列 19】region 分布不均问题排查及解决不完全指南

一. 背景描述 大家在使用 TiDB 的过程中有可能会遇到 Region 和 Leader 分布不均的情况，监控信息如下： leader 信息： [image] region 信息： [image] 虽然最终解决了问题，但是整个排查及优化的过程还是很繁琐的，主要是因为架构的复杂度及对基础参数的不了解。为了方便以后对此类 region 分布不均问题的处理，结合官方文档的给出的思路…

[dba-kit (张天师)]

@xfworld

大量的数据 GC，慢查询， 等等都会导致这个负载高的问题

这个确实是，分布式系统排查起来很麻烦:mask:

[dba-kit (张天师)]

@dba-kit

KvService response batch commands fail
Coprocessor task terminated due to exceeding the deadline

这两个报错信息代表什么含义，你知道么？官方文档里没找到对应的说明。。。

---

还有就是TiKV-Detail ==> RocksDB-kv ==> Number of Snapshots这个监控里的Snapshot是指什么也不清楚。这个值突然飙升代表什么含义？
官方把Snapshot在不同场景有不同含义，我找的有两种：

1. 在隔离级别里：RC是基于Snapshot隔离的，每个事务创建时候，都会创建一个Snapshot
2. 在TiKV 源码解析系列文章（十）Snapshot 的发送和接收 | PingCAP中：Snapshot是指状态机的快照

[dba-kit (张天师)]

多谢，这个很有帮助

[xfworld (魔幻之翼)]

Snapshots 就是指某个时间点数据的快照，
数据的版本越多，涉及的事务越多的话，快照必须越多

因为需要支持到隔离级别