分布式计划执行时中间结果占用内存过大

问题现象

DtlIntermRes 这个 mod 的内存占用过大。

可以通过如下语句查看该模块占用的内存。

obclient> select * from oceanbase.__all_virtual_memory_info where label = 'DtlIntermRes';

关键诊断信息

分布式计划，中间结果集大。

问题原因

• 设计问题。所有中间结果的落盘是由一个后台线程完成的，写入速度较大时落盘跟不上，会导致占用内存越来越大。

• 存在一个 BUG，在读落盘的中间结果时，会申请内存存放数据，读完以后会释放内存释。为了避免频繁申请释放内存，这里做了优化，不会真正把内存释放掉，而是放入 free_list_ 中等待后续复用。导致 free_list_ 中的内存没有得到复用。BUG 导致 free_list 中的内存没有得到复用，因此使用的内存越来越多。

问题的风险及影响

分布式计划执行时如果中间结果集比较大，占用内存比较多。

影响租户

影响 OceanBase 数据库中的 Oracle 租户和 MySQL 租户，对于 SYS 租户无影响。

影响版本

OceanBase 数据库企业版 V2.2.77 GA（oceanbase-2.2.77-20210508211731）及之后版本、V3.1.2 GA（oceanbase-3.1.2-20210618150922）及之后版本、V3.2.3 GA（oceanbase-3.2.3.0-20220418212020）及之后版本、V3.2.4 GA（oceanbase-3.2.4.0-100000072022102819）及之后版本、V4.1.0 GA（oceanbase-4.1.0.0-100001122023040322）及之后版本。

解决方法及规避方式

• 升级至问题已修复版本。目前已修复的版本包括 OceanBase 数据库企业版 V3.2.3 BP11（oceanbase-3.2.3.3-111000032024070822）、V3.2.4 BP6（oceanbase-3.2.4.6-106000062023110109）。

• 对于存在这样问题的 SQL，可以使用 hint /*+ parallel(2) */ 开启并行，并行度大于 1 时是流式执行，不会写中间结果。

• 通常生成计划时会避免 transmit 发送那么大的数据，出问题的 SQL 最终的输出结果有几十亿行。可以检查一下问题 SQL 是否合理，或者对计划进行调整。