临时文件过大占用过多磁盘空间

问题现象

问题表现是磁盘占用过高，通过下面方式看到是临时文件占用的空间比较大。

关键诊断信息

触发条件

无。

事前巡检

存在执行时间比较久，并行度等于 1 的分布式计划，并且部分 transmit-receive 之间发送的数据量比较大。 可以直接查看 __all_virtual_dtl_interm_result_monitor，order by dump_size desc limit 20;（按 dump_size 降序排序输出限制 20 行）会展示当前落盘比较多的中间结果。

事后诊断

首先查看是不是临时文件占用磁盘空间比较多，使用下面的 SQL，观察 file type 为 tenant tmp data 的记录。

select * from oceanbase.__all_space_usage where svr_ip = 'xxx' and svr_port = xx;

确认是临时文件占用比较多以后，过滤关键词命令。

grep "succeed to open a tmp file"

可以看到大量的 dir 相同，fd 不断增长的打开临时文件的日志。

最后再看一下移除临时文件的日志，执行下面的命令。

grep 'succeed to remove a tmp file' observer.log* | grep -o 'fd=[0-9]*' | awk -F '=' '{print $2}' > remove.fd

执行结果中可以看到，在移除了 32 万多编号的临时文件后才移除编号 3 万多的临时文件，编号突然变小了很多。

问题原因

1. 写临时文件时要指定 dir_id 和 fd，即指定目录和文件 id。

2. 同一个目录下的临时文件可能共享一个宏块，一个临时文件的数据也可能写在多个宏块中。 比如有 A，B，C 三个 store 的数据在落盘，每个 store 对应一个文件，三个文件处于同一个目录中。向临时文件中写数据，可能A先落盘，向宏块 1 中写一部分数据，然后 B 落盘接着向宏块 1 写数据，然后 C 落盘将宏块1写满开始向宏块 2 写数据。随后 A 又再次落盘，向宏块 2 写数据。

3. 只有一个宏块中的所有文件都被移除了，这个宏块才能被释放。以上面的为例，如果 A 被移除了，那么宏块 2 可以被释放，但是宏块 1 无法释放，因为还有 B 和 C 对应的文件也在其中写了数据。

4. 分布式计划执行过程中，在并行度等于 1 的场景下，EXCHANGE OUT 算子发送的数据会在 EXCHANGE IN 所在节点上被记录到中间结果中，随后 EXCHANGE IN 会从中间结果中将数据读出来。

5. 问题是，一个节点上的所有中间结果在落盘时，都使用了同一个 dir_id, 它们的临时文件都在一个目录下。这导致在存在大查询的情况下，这条查询的中间结果对应的临时文件所涉及的宏块会长时间无法被释放。尤其是这个中间结果不是一次性全部落盘的，可能会多次落盘每次落盘一部分数据，那么它就会涉及非常多的宏块，每个宏块中只占据一小部分空间但是这整个宏块都无法释放。

问题的风险及影响

导致磁盘占用过高。

影响租户

影响 OceanBase 数据库中的 SYS 租户和 Oracle 租户以及 MySQL 租户。

影响版本

OceanBase 数据库企业版 V3.1.2 GA（oceanbase-3.1.2-20210618150922）及之后版本、V3.2.2 GA（oceanbase-3.2.2-20211130225726）及之后版本、V3.2.3 GA（20220419）及之后版本、V3.2.4 GA（oceanbase-3.2.4.0-100000072022102819）及之后版本、V4.1.0 GA（oceanbase-4.1.0.0-100001122023040322）及之后版本、V4.2.0 GA（oceanbase-4.2.0.0-100010082023083014）及之后版本、V4.2.1 GA（oceanbase-4.2.1.0-100000182023092722）及之后版本、V4.2.2 GA（oceanbase-4.2.2.0-100000082024011317）及之后版本、V4.3.0（oceanbase-4.3.0.0-100000072024020200）及之后版本。

解决方法

• 磁盘占用已经很高的话可以考虑先重启该节点。

• 找出大查询。查看 __all_virtual_dtl_interm_result_monitor，order by dump_size desc limit 20;（按 dump_size 降序排序输出限制 20 行） 会展示当前落盘比较多的中间结果，利用 trace_id 和 __all_virtual_processlist 做关联找到对应的 query。从应用侧限制大查询的频率，或者调低配置项 large_query_worker_percentage 的值。

• 升级至问题已修复版本。目前已修复的版本包括 OceanBase 数据库 V3.2.4 BP5 Hotfix9（oceanbase-3.2.4.5-105090022024061012）、V3.2.4 BP5 Hotfix10（oceanbase-3.2.4.5-105100032024072515）、V3.2.4 BP5 Hotfix11（oceanbase-3.2.4.5-105110022024103122）、V3.2.4 BP5 Hotfix12（oceanbase-3.2.4.5-105120022025030712）、V3.2.4 BP5 Hotfix13（oceanbase-3.2.4.5-105130022025032811）、V3.2.4 BP5 Hotfix14（oceanbase-3.2.4.5-105140012025062619）、V3.2.4 BP5 Hotfix15（oceanbase-3.2.4.5-105150012025081820）、V3.2.4 BP5 Hotfix16（oceanbase-3.2.4.5-105160032025091816）、V3.2.4 BP5 Hotfix17（oceanbase-3.2.4.5-105170082025100222）、V3.2.4 BP5 Hotfix18（oceanbase-3.2.4.5-105180012025111714）、V4.2.1 BP8（oceanbase-4.2.1.8-108000052024072217）及之后版本。

规避方式

通常不会遇到这个问题，和业务模式，磁盘空间大小有关，可以在磁盘空间报警时通过上述方式判断是否命中这个问题进行规避。