SQLSTAT 会在用户执行过多 Command 的场景下占用过多内存的原因和解决方法

问题现象

OB_SQLSTAT_OBJ 占用大量内存。

关键信息

OB_SQLSTAT_OBJ 占用过多内存。

问题原因

SQLSTAT 会对所有执行的sql请求在 Library Cache 中分配一块内存，存储 SQL 执行过程中的信息，SQLSTAT 还会为没有计划的 SQL 请求分配内存，比如 commit、set、alter 等，当用户执行这类命令很多时，会导致 Library Cache 分配太多内存，挤占正常计划的内存。

问题的风险及影响

一个 SQLSTAT 对象占用的内存大约 1.5K，淘汰后会因为 MEMCTX(16K) 形成了很多内存碎片。因此 SQLSTAT 淘汰了之后内存 Hold 不下降。 Library Cache 依赖 Tenant Allocator 的 Memory Hold 的内存来触发的，每次淘汰掉 Memory Used 的一半内存下去，淘汰过程中会产生内存碎片导致 Memory Hold 降得比较缓慢，所以会一直触发淘汰。 后续新 SQL 流量进入后，发现没有 Plan Cache，就需要执行硬解析，形成新计划，再将新计划加入到 Library Cache 中，但是由于 Library Cache 内存 Hold 超过 Limit，所以无法在 Library Cache 中新增元素。从而导致一次短暂的血崩。等到下一次 Library Cache 淘汰掉大批量内存后，系统又恢复正常。所以 TPS 表现出正常->下跌->正常的性能波动。

适用版本

OceanBase 数据库 V4.2.2 GA（oceanbase-4.2.2.0-100000082024011317）及之后版本。

解决方法

关闭 SQLSTAT 功能，命令如下。

ALTER SYSTEM SET _ob_sqlstat_enable = false;

规避方式

关闭 SQLSTAT 功能，且进行一次 Library Cache 的 FLUSH 操作。

ALTER SYSTEM SET _ob_sqlstat_enable = false;
ALTER SYSTEM FLUSH LIB CACHE NAMESPACE="SQLSTAT" global;