TiFlash OOM 起不来(生产节点)

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:
【 TiDB 使用环境】
tidb: 4.0.13

【概述】 场景 + 问题概述
生产节点,tiflash 挂掉一台, 重启不来,tiflash 72G 内存,查看监控发现内存暴涨,直到OOM,再次重启,无限循环,加了两个内存限制60G,还是不管用,一样OOM
image

【业务影响】
tiflash服务不可用

【 TiDB 版本】
4.0.13

【附件】 相关日志及监控(https://metricstool.pingcap.com/)
1628042433
1628042433(2)

日志:
tiflash.zip (4.2 MB)

在545145行,又是重启的新日志

若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出的打印结果,请务必全选并复制粘贴上传。

2 个赞

Hi ~ 看现象应该是 SQL 的大查,麻烦先定位一下 TiDB 是否有大的 query。 可以参考一下这个帖子,调整一下相应的 TiFlash 参数 。tidb4.0.0版-使用TiFlash一直重启,如何定位问题

这个帖子也说了,只是缓解作用吧,并且如果是sql大查,那重启了,连接也断了,为啥还会一直OOM起不来呢

麻烦看一下数据目录下面的数据分布情况,看看是否已知问题。比如:

du -sh <tiflash_data_dir>/data//log
du -sh <tiflash_data_dir>/data/
/stable

image

@flow-PingCAP data目录下面是真实数据目录了,没有log和stable

1 个赞

麻烦执行下面的命令,我们确认下数据分布

du -sh <tiflash_data_dir>/data/*/* | sort -k1hr | head -n 50
du -sh <tiflash_data_dir>/kvstore/*

1 个赞

再使用下面的命令,确认下 kvstore 目录下以 ‘legacy’ 为开始的目录数量

find <tiflash_data_dir>/kvstore/ -name 'legacy*' | wc -l

另外我现在为了不影响线上使用,先扩容了一个节点,然后缩容这个节点,等这个节点缩容后重新扩回来。不知道缩容这个操作会不会影响这个目录下文件的分布

确认下,进行缩容操作是指使用 tiup scale-in 命令么?
执行缩容命令之后,这个 TiFlash 节点还是处于反复 oom 重启的状态么?

是用scale-in 缩容

执行缩容后,该节点tiflash进程已经不存在了,没有OOM,我是怕我的下线操作影响上面的数据分布,影响你判断,所以说一声

现在能辨别出来问题原因吗,以及后续如何避免,tiflash oom我们已经遇到这是第四次了,前三次都是在4.0.11版本,直接机器都连不上了,后来看到4.0.13有修复,就升级了,现在又出现了这个问题,生产出现了4次同样的问题,有点头疼。。

1 个赞

嗯,基本可以确认存在一个已知问题。
在写入量较大,或者运行相对长时间之后,由于一些 GC 策略的问题,在硬盘上积累了比较多 ‘legacy’ 的文件(一般单个目录下维持在数百以内算是正常,这里 kvstore 目录下已经积累到 6000+)。大量的 ‘legacy’ 文件在运行的过程中会导致内存有明显的波动。

这个问题最近在我们内部长稳测试中发现并进行了修复,但是还没有 pick 到发布的版本中。

那这是个新bug是吧,不在下面这两个的修复中:


那预计是会在什么版本修复呢,目前需要做的只能是重新下线再重新扩容个回来,无法通过修改参数让他直接起来是吧? 另外想了解下这个legacy文件是干什么用的

请问有没有可能等修复发布后升级到5.0.5或者5.1.2版本?

有可能的,我们目前是调研的5.0.2,后续如果5.0.5近期发版正好赶上我们就简单测试下就应该可以了上

现在的情况是只能通过重新扩缩容来恢复该节点是吗,legacy是干什么用的?不能删除来修复是吗

1 个赞

另外我们另外两个tiflash节点这个文件也是5500+,目前来说有什么办法缓解呢,如果另外两个节点也因为这个问题OOM起不来,那我们生产就直接挂了,我们得做一些必要的防护措施

legacy是干什么用的?不能删除来修复是吗

可以认为目录下的数据 GC 分两个阶段,第一个阶段会回收 ‘page_xxx/page’ 这块空间,然后形成 ‘legacy.page_xxx’ 这样的文件夹。第二个阶段会回收 ‘legacy.page_xxx’ 这样文件里面的内容。由于一些 bug,导致第二个阶段无法顺利推进,留下比较多的文件,引起上面的现象。
不能直接删除那些文件,否则会导致 TiFlash 上的数据丢失。

另外我们另外两个tiflash节点这个文件也是5500+,目前来说有什么办法缓解呢

目前可以提供离线工具可以对数据进行整理。需要先停止 TiFlash 的进程,使用工具对数据进行整理,整理好了之后再重新启动 TiFlash 节点。请问这样的方式可以接受吗?

1 个赞

不能接受的,直接影响了线上使用的

听上面的描述,目前是一共 3 个 TiFlash 节点,其中 1 个节点发生了这个情况,扩容了新的节点。对目前的线上查询没有影响?可以确认 TiFlash 的 replica 数量是否都设置了 2 个副本?
是否可以等待 TiFlash 的 Region 副本数都补充到 2 个,然后对剩下的两个 TiFlash 节点逐个进行停机的数据整理?这样对线上使用的影响能够降低。