TIKV CPU 爆了

[等一分钟]

【 TiDB 使用环境】生产环境 /
【 TiDB 版本】 v6.5.1
【遇到的问题：问题现象及影响】
TIKV 节点的CPU 一直在95%以上
【资源配置】
5个TIKV节点, 16C32G
【附件：截图/日志/监控】

[等一分钟]

会是什么原因啊

[db_user]

补充下tikv的日志，overview的监控，tikv的detail的cpu监控，还有dashboard的慢日志情况，tidb的监控，常见的情况有热点，大量慢sql,自动analyze导致的问题等，还需要具体情况来分析

[xfworld (魔幻之翼)]

资源不足的前后有做什么操作么？

[等一分钟]

就是各个SQL在查，一般tikvCPU高，能说明什么问题啊

[xfworld (魔幻之翼)]

1. 数据规模和资源配置不合理

2. 使用方式不太对，需要参考最佳实践做优化

3. slow Query 太多了，导致资源占用，长时间无法释放

---

建议判断下业务需求的场景和数据规模，当前的资源配置是否能覆盖？
然后通过Dashboard 的 Top N 的方式查看资源占用较多的 Query 先进行优化

[tidb菜鸟一只 (小菜一颗)]

grafana里面tikv-details里面Thread CPU看看是那部分占的cpu比较多

[Billmay表妹 (表妹)]

TiKV 节点的 CPU 使用率一直保持在 95% 以上可能是由于多种原因导致的，以下是一些可能的原因和解决方法：

1. 存在大量的 Tombstone key 没有完成 Compaction 操作，导致大量 SQL 扫描大量无用数据，导致 TiKV 的 Storage ReadPool CPU 被打满，最终导致 TiKV 繁忙，处理请求响应缓慢。可以通过 TiKV-details 监控面板查看 TiKV 实例的 CPU 使用率和 Storage ReadPool CPU 使用率，以及通过应用报错对应 TiDB Server 查询集群的元数据 Region 是否在出现 CPU 异常的 TiKV 实例上面，来判断是否存在这个问题。如果存在这个问题，可以通过 Compaction 操作来解决。

2. 存在内存故障导致的"热点"问题。可以通过检测硬件来确定是否存在内存故障，如果存在内存故障，可以先向集群加入一台新服务器，再下掉有问题的服务器。可以先在新服务器上扩容 TiKV 实例，再逐个缩容掉问题服务器上的 TiKV 实例，完毕以后，集群 Duration 恢复到之前状态，TiKV 服务器的 CPU 比较均衡。

3. 存在异常 SQL 导致的热点问题。可以通过分析慢日志，查看是否存在异常 SQL，如果存在异常 SQL，可以对其进行优化或者调整 TiKV 集群的配置参数来解决。

4. 存在其他问题，比如 CPU、内存、IO、网络等问题。可以通过监控面板查看各组件服务器的 CPU、内存、IO、网络等情况，来判断是否存在这些问题。如果存在这些问题，可以根据具体情况进行相应的优化或者调整 TiKV 集群的配置参数来解决。

希望以上信息能够帮助您解决 TiKV 节点 CPU 使用率过高的问题。

[等一分钟]

感谢啊

[maokl]

应该有慢sql吧