tmp-storage-path占用空间过大问题

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:

【TiDB 版本】
4.0.8

【问题描述】
tmp-storage-path目录使用超过600G, SQL语句执行完之后,会回收临时磁盘吗?
tmp-storage-quota设置了会 返回 Out Of Global Storage Quota! 错误,这个参数建议设置吗?
tmp-storage-path太大要怎么处理呢?


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

image
这些好多天之前的文件可以直接删除吗?

理论上,tmp 目录下的文件,在 sql 执行完成后,会释放对应的空间。上面的问题确实看起来可能是非预期的现象 ~

tmp 目录下的文件处理

  • 3 月 16 日产生的 chunk.ListInDisk 文件可以根据当前 SQL 执行的情况,来尝试手动删除。删除前,请使用 lsof chunk.ListInDisk-xxxx 看一下 这些文件是否还被 tidb 持有,来释放下磁盘空间,理论上不会有什么影响的 ~

针对这个问题,论坛上也有其他老师遇到了,正在分析定位中,后续可以关注下该帖的进度:

好的,感谢

这个也需要看下哈,这些文件是否仍然被 tidb 持有 ~

好的,:smile:

请问下,3 月 16 日的 chunk.ListInDisk-xxxx 相关的文件在确认 SQL 执行完毕,且 TiDB 不再占用后。删除该文件空间是否释放,以及 TiDB Server 是否因删除该文件出现异常现象 ?

另外,为了进一步排查这个问题,您那里方便提供下,下面的信息吗?

  • 3 月 16 号(tmp 文件遗留的时间点)09:00 ~ 12:00 间的 TiDB Server 的日志
  • 3 月 16 号 使用到 tmp 目录空间的这些 sql 是否执行成功了

以上,辛苦了,谢谢 ~

  • 删除之后空间释放了,目前没有发现tidb有异常现象
  • 使用tmp 目录空间的这些 sql应该都是执行成功的,今天因为磁盘报警才发现这个问题的
    tidb_20210316.log (3.7 MB)

好的,收到,这边分析下。如果有进度,会及时跟帖 ~

另外,辛苦观察下上述现象是否是 100% 可以复现的,比如,当出现使用 /tmp 目录的 sql ,并且在该 sql 执行完毕后,/tmp 的空间是否释放。以及记录下使用 /tmp 目录的 sql 的 explain analyze 的执行计划是怎样的 ~

以上,辛苦了,谢谢 ~

附件里的sql是每10分钟跑一次,和 /tmp目录下chunk.ListInDisk文件的生成时间刚好能对上,是100%复现的
执行计划有时候用到disk,有时候没有用到disk,具体信息都在附件里了
附件.txt (6.9 KB)

好的,收到,感谢回复,这边再看下,如有进度会及时跟帖 ~

您好,这个问题目前定位是因为在 v4.0.8 中,Shuffle 算子的 Close 函数没有将 worker 所持有的 Executor 一并 Close 掉,导致了资源泄漏。当前您那里的 SQL 语句和这个的情况描述相符。

目前有以下三个方案来解决这个问题:

方案一:可以通过将 window 算子的并发度 tidb_window_concurrency 调整到 1, 关闭 Shuffle 加速Window function 的功能,来避免落盘文件不删除的问题。可能会导致 SQL 有一定的性能回退,这块需要注意,建议根据当前业务情况进行评估

方案二:定期删除 /tmp/…/tmp-storage 里的文件。

方案三:如果机器内存够用,建议调大 tidb_mem_quota_query 来避免落盘。

该问题预计会在 4.0.13 中 fix ,后续可以关注官网的发版信息 :

好的,感谢

:handshake::handshake::handshake: