为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【 TiDB 使用环境】
tidb: 4.0.13
【概述】 场景 + 问题概述
生产节点，tiflash 挂掉一台， 重启不来，tiflash 72G 内存，查看监控发现内存暴涨，直到OOM，再次重启，无限循环，加了两个内存限制60G，还是不管用，一样OOM
【业务影响】
tiflash服务不可用
【 TiDB 版本】
4.0.13
【附件】 相关日志及监控（https://metricstool.pingcap.com/)
日志：
tiflash.zip (4.2 MB)
若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。
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
麻烦执行下面的命令，我们确认下数据分布
du -sh <tiflash_data_dir>/data/*/* | sort -k1hr | head -n 50
du -sh <tiflash_data_dir>/kvstore/*
再使用下面的命令，确认下 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次同样的问题，有点头疼。。
嗯，基本可以确认存在一个已知问题。
在写入量较大，或者运行相对长时间之后，由于一些 GC 策略的问题，在硬盘上积累了比较多 ‘legacy’ 的文件(一般单个目录下维持在数百以内算是正常，这里 kvstore 目录下已经积累到 6000+)。大量的 ‘legacy’ 文件在运行的过程中会导致内存有明显的波动。
这个问题最近在我们内部长稳测试中发现并进行了修复，但是还没有 pick 到发布的版本中。
那这是个新bug是吧，不在下面这两个的修复中：
那预计是会在什么版本修复呢，目前需要做的只能是重新下线再重新扩容个回来，无法通过修改参数让他直接起来是吧？ 另外想了解下这个legacy文件是干什么用的
请问有没有可能等修复发布后升级到5.0.5或者5.1.2版本？
有可能的，我们目前是调研的5.0.2，后续如果5.0.5近期发版正好赶上我们就简单测试下就应该可以了上
现在的情况是只能通过重新扩缩容来恢复该节点是吗，legacy是干什么用的？不能删除来修复是吗
另外我们另外两个tiflash节点这个文件也是5500+，目前来说有什么办法缓解呢，如果另外两个节点也因为这个问题OOM起不来，那我们生产就直接挂了，我们得做一些必要的防护措施
legacy是干什么用的？不能删除来修复是吗
可以认为目录下的数据 GC 分两个阶段，第一个阶段会回收 ‘page_xxx/page’ 这块空间，然后形成 ‘legacy.page_xxx’ 这样的文件夹。第二个阶段会回收 ‘legacy.page_xxx’ 这样文件里面的内容。由于一些 bug，导致第二个阶段无法顺利推进，留下比较多的文件，引起上面的现象。
不能直接删除那些文件，否则会导致 TiFlash 上的数据丢失。
另外我们另外两个tiflash节点这个文件也是5500+，目前来说有什么办法缓解呢
目前可以提供离线工具可以对数据进行整理。需要先停止 TiFlash 的进程，使用工具对数据进行整理，整理好了之后再重新启动 TiFlash 节点。请问这样的方式可以接受吗？
不能接受的，直接影响了线上使用的
听上面的描述，目前是一共 3 个 TiFlash 节点，其中 1 个节点发生了这个情况，扩容了新的节点。对目前的线上查询没有影响？可以确认 TiFlash 的 replica 数量是否都设置了 2 个副本？
是否可以等待 TiFlash 的 Region 副本数都补充到 2 个，然后对剩下的两个 TiFlash 节点逐个进行停机的数据整理？这样对线上使用的影响能够降低。
