TIKV内存占比很高,TIKV无法启动,SQL查询失败

【 TiDB 使用环境】生产环境
【 TiDB 版本】6.1.2
【复现路径】做过哪些操作出现的问题,上一个版本的集群是5.1.3,我们降低了tikv的配置,从16核32GB降低到了8核32G。以及把tikv升级到了6.1.2版本。
【遇到的问题:问题现象及影响】上一个版本5.1.3内存占比在缩减配置后,内存占比变的更高了,但是没有出现TiKV omm掉线重启的情况,后来我们看到官方新版本有对内存的优化,所以我们升级到了6.1.2版本,之后内存就一直95%,只要有大查询就会导致tikv omm掉线重启。

另外一个sql之前查询是没有问题的,但是最近在tikv不稳定的情况下,以及版本升级后,直接无法查询,不知道是不是sql的某个规则在新版取消导致的还是什么问题。

今天在正常业务服务期间,有比较高的qps,并且内存占比很高,由于业务需要,向集群中写入数据,导致tikv omm掉线,但是这次掉线后就无法自动重启。

【资源配置】
【附件:截图/日志/监控】

日志呢?

tikv的内存设置参数你们是怎么设置的?

所有的组件都升级到了 6.1.2 还是只有 tikv 升了其他没有升级?

生产环境请按照官方要求部署~

经过这几天的排查和分析,也特别感谢tidb社群的朋友帮助,我把解决的过程记录下。

首先内存占比很高的问题,我们设置了内存参数就好了,内存占比就不会太高。
可以参考这个帖子:【线上运维之06】TIDB在线更改TIKV内存占比,解决频繁OOM问题 - 能胜的个人页面 - OSCHINA - 中文开源技术交流社区

tikv无法启动是因为顺坏了文件,有两种处理办法,一种是下线节点后重新添加,但是非常耗时,我们用的是这个方法,帖子的链接社群文档自行搜索下。

但是另外一种办法是找到损坏的文件并修复,通过 TiKV Control工具,打印损坏的 SST 文件信息,然后在通过修复工具修复或者忽略启动,我们没有尝试,所以具体操作顺序社群文档搜索。

[TiKV Control 使用说明]
(https://docs.pingcap.com/zh/tidb/dev/tikv-control#强制-region-从多副本失败状态恢复服务弃用)

问题3,sql查询失败,是因为我们一个用with写的sql的子查询不走索引,经过我们的排查,在自查询的 tabel 后面增加一行代码。FROM table_name FORCE INDEX (‘索引名’),查询速度就恢复正常了,后来我们做了表分析,ANALYZE TABLE table_nam 发现不加强制索引也正常了。

最后查询速度也和tikv内部有没有错误有关,比如数据分布是否均匀等,性能都会有所提升。

2 Likes