一、背景
在客户测试环境中（GaussDB 506.0 SPC0100 集中式），一个重度使用存储过程的系统，频繁出现内存临时不可用的问题(ERROR: memory is temporarily unavailable)。令人困惑的是，这个环境配置的内存大小已经数十倍于迁移前的Oracle。
二、GaussDB提供的观测方法
GaussDB官方产品文档中有一个《内存过载》章节，详细描述了在出现内存过载情况下如何定位，但似乎这个章节并没有在官方网站上公开。下面按照本次分析过程进行描述。
内存监控视图
GaussDB提供了几个重要的内存视图：
gs_total_memory_detail
显示当前数据库节点的内存使用情况，单位为MB。当GUC参数enable_memory_limit的值为off时，本视图不可用。
gs_session_memory_detail
显示会话的内存使用情况，以MemoryContext节点来统计。当开启线程池（enable_thread_pool = on）时，该视图包含所有线程和会话的内存使用情况。当GUC参数enable_memory_limit的值为off时，本视图不可用。
gs_shared_memory_detail
查询当前节点所有已产生的共享内存上下文的使用信息。
内存使用情况示例
SELECT * FROM gs_total_memory_detail;
|----------|----------------------------------|--------------|
| nodename | memorytype | memorymbytes |
| primary | max_process_memory | 24567 |
| primary | process_used_memory | 7847 |
| primary | max_dynamic_memory | 16651 |
| primary | dynamic_used_memory | 1843 |
| primary | dynamic_peak_memory | 2942 |
| primary | dynamic_used_shrctx | 1286 |
| primary | dynamic_peak_shrctx | 1387 |
| primary | max_backend_memory | 1360 |
| primary | backend_used_memory | 1 |
| primary | high_backend_thread_memory | 20 |
| primary | high_backend_thread_max_memory | 768 |
| primary | medium_backend_thread_memory | 113 |
| primary | medium_backend_thread_max_memory | 1536 |
| primary | low_backend_thread_memory | 0 |
| primary | low_backend_thread_max_memory | 768 |
| primary | max_shared_memory | 6548 |
| primary | shared_used_memory | 5402 |
| primary | max_cstore_memory | 16 |
| primary | cstore_used_memory | 0 |
| primary | max_sctpcomm_memory | 0 |
| primary | sctpcomm_used_memory | 0 |
| primary | sctpcomm_peak_memory | 0 |
| primary | other_used_memory | 527 |
| primary | gpu_max_dynamic_memory | 0 |
| primary | gpu_dynamic_used_memory | 0 |
| primary | gpu_dynamic_peak_memory | 0 |
| primary | pooler_conn_memory | 0 |
| primary | pooler_freeconn_memory | 0 |
| primary | storage_compress_memory | 0 |
| primary | udf_reserved_memory | 0 |
| primary | llvm_used_memory | 0 |
| primary | max_htap_memory | 0 |
| primary | htap_used_memory | 0 |
内存类型理解指南
要真实理解gs_total_memory_detail里这些内存类型的关系，并且理解gs_session_memory_detail和gs_shared_memory_detail记录的内存对应到gs_total_memory_detail的映射关系，需要明确以下几点：
内存指标含义
max：表示最大可以为多少，超过就会报内存不足
used：表示当前已经申请了多少
peak：表示本次数据库启动以来的历史used峰值
内存分配关系
max_process_memory 是通过参数设置的
max_shared_memory主要为shared_buffers，但是这个值的大小可能会比shared_buffers要大
max_dynamic_memory是 max_process_memory - max_shared_memory - max_cstore_memory - max_backend_memory - ... 得到的
dynamic_used_memory 包括了：
动态会话内存（gs_total_memory_detail里没列出来）
dynamic_used_shrctx
high_backend_thread_memory
medium_backend_thread_memory
low_backend_thread_memory
💡 注意：后三个high/medium/low暂时不用关心，这是新版本中引入的特性，为后台线程专门分出来的内存。
GaussDB内存区域划分
在GaussDB中，主要的内存区域分为：
📁 共享内存（主要为shared_buffers）
📁 动态内存（dynamic_memory）
├── 📄 动态会话内存 (gs_session_memory_detail)
├── 📄 动态共享内存 (dynamic_used_shrctx) (gs_shared_memory_detail)
└── 📄 动态后台内存
⚠️ 重要提醒：这里出现两个"共享内存"，非常容易产生理解上的歧义。比如gs_shared_memory_detail这个视图，查的就不是"共享内存"，而是"动态共享内存"。
可以这么理解：
shared_buffers主要是data buffer，即表和索引的数据
GaussDB实现的global plan cache/global plsql cache/unique sql hash table等全局缓存，并不属于shared_buffers，而是在dynamic_used_shrctx里
内存追踪配置
内存不足的报错经常是一个瞬间冲高，回头再来看这些视图时，已经找不到对应的内存上下文，因此GaussDB在出现内存不足的报错时，会自动把当时的内存上下文情况生成到单独的日志文件中。
memory_trace_level 参数
参数说明：动态内存使用超过最大动态内存的90%后，记录内存申请信息的管控等级。该参数仅在GUC参数use_workload_manager和enable_memory_limit打开时生效。
参数类型：枚举类型
参数单位：无
取值范围：
|------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 级别 | 说明 |
| none | 表示不记录内存申请信息 |
| level1 | 动态内存使用超过最大动态内存的90%后，会记录以下信息，并将记录的内存信息保存在$GAUSSLOG/mem_log目录下： • 全局内存概况 • instance，session，thread三种类型的所有内存上下文中内存占用前20的内存上下文的内存使用情况 • 每个内存上下文的totalsize、freesize字段 |
| level2 | 在level1的基础上，还会记录每个内存上下文上所有内存申请的详细信息，包含申请内存所在的文件，行号和大小 |
默认值：level1
⚠️ 设置建议：该参数设置为level2后，会记录每个内存上下文的内存申请详情（file，line，size字段），会对性能影响较大，需慎重设置。
相关功能：
记录的内存快照信息可以通过系统函数gs_get_history_memory_detail(cstring)查询
记录的内存上下文是经过将同一类型所有重名的内存上下文进行汇总之后得到的
三、现场分析
初步发现
由于默认是level1，没有记录申请内存的源码文件和行号，因此后面现场调成了level2。
当时的mem_log中有记录两个比较可疑的内存上下文：
|----------------|-----------------------|----|------|
| 位置 | 上下文名称 | 数量 | 大小 |
| shared_memory | unique sql hash table | 1个 | ~8G |
| session_memory | SRF multi-call contex | 1个 | ~8G |
然后回头查gs_shared_memory_detail、gs_session_memory_detail这两个视图，发现的确可以查到unique sql hash table占了8G，但是查不到SRF multi-call context。
监控脚本
客户DBA写了个监控脚本，每隔20秒采集一下各个内存视图的数据。
但几天后，仍然没有采集到SRF multi-call context，而数据库日志中仍然会时不时报错内存临时不可用。
关键发现
在一次偶然的连续查询gs_total_memory_detail时，发现已使用的动态内存上下波动幅度高达8GB。
于是猜想可能是一个非常短的时间产生了SRF multi-call context这个上下文，执行完后就释放了，所以间隔20秒采一次能采到的概率非常低。
深入分析
数据库大厂的内核研发往往都只负责各自一小块领域，华为内核研发远程查看日志，并没有发现什么可疑的点，而且还拉了好几个不同领域的内核研发，都没有找到原因。
但是在远程会议中，客户快速一页一页翻日志时，我发现一个现象：
在出现内存临时不可用报错的前面一段，会频繁打印相同格式的日志，而且中间有个数字一直在涨，从1XXXXXXXXX一直涨到7XXXXXXXXX，然后就没有这个重复日志了。
直觉告诉我，很可能与这个有关。于是让客户回到这段日志前面，然后发现了类似下面的这么一行：
2025-07-25 10:00:01.523 primary RdsAdmin postgres xxx.xxx.xxx.xxx 140216907527936 12[0:0#0] 0 gsql 00000 31806672368306287 [BACKEND] LOG: 00000: unique_sql_id=3740540431, Current SQL is consuming about 1099 MB, allocating 102921000 bytes, memctx:SRF multi-call context, appname:, user_id: 16616, current query is: select usename,count(*) from dbe_perf.statement group by usename
问题串联
很明显这里就出现了SRF multi-call context，然后这段日志下面就是不断地在申请内存，直到申请了8G，后面很快就有一个业务调用存储过程报错内存不足了。
也就是说，在这个环境中，查询一次dbe_perf.statement这个视图，就会申请8G内存。这个查询，是TPOPS端定时采集的SQL。
dbe_perf.statement这个视图里实际上是一个查询特定内存数据的返回多行的函数，查询的就是unique sql hash table里的内容。
问题链条分析
分析到这里，感觉大部分疑点都串起来了：
由于某种原因，归一化SQL的内存达到了8G
然后由于TPOPS定时查询dbe_perf.statement，导致内存瞬间又消耗了8GB
光这两个动态内存上下文就占了16GB
由于这是个重度存储过程的系统，GLOBAL PLSQL CACHE又占了几个GB
动态内存全用完了，导致业务会话报错
进一步探究
归一化内存为什么会达到8GB？
我在很早就问过华为内核研发：track_activity_query_size=40960这么设置，如果SQL没达到这个长度，占用的内存是SQL实际的长度还是40960？
我一直记得在openGauss系数据库中，这个内存一定是按设置的这个大小申请，不会根据SQL实际长度变化，但是华为内核研发说在GaussDB中内存占用只会按实际SQL长度来，除非SQL长度达到或者超过这个数，才会申请这么多内存。
由于GaussDB并没有开源，所以当时我只能相信华为说的，可能GaussDB做了优化。
巧合的乘积
可是客户现场出现这个现象时，我直接计算了下：
40,960 × 200,000 = 8,192,000,000
刚好差不多8G，这么巧合？
然后客户也查了，实际在dbe_perf.statement里query的汇总字节数，也就只有一百多MB。
但是华为内核研发说他看了那段代码，说的确是按实际长度来的，但是他又无法解释这8GB到哪里去了，因为算上其他属性的长度，每行最多就再加几百KB。
四、问问万能的AI
GaussDB没开源，但是openGauss是开源的，本来想用Cursor来分析一下，奈何被断供了，只能先用vscode的Copilot了。
打开openGauss源码目录，切换Copilot到agent模式，开问：
第一轮提问
Dark-Athena: 看下SRF multi-call context 这个上下文在什么时候会产生
GitHub Copilot ：内容较长具体可点击文末左下角查看原文获取
总结：SRF multi-call context 在任何集合返回函数第一次被调用时产生，用于在函数的多次调用之间保持状态和数据，直到函数返回完所有结果后被清理。
第二轮提问Dark-Athena: 分析下执行get_instr_unique_sql这个函数时，申请的"SRF multi-call context"占用大小与什么有关
GitHub Copilot: 内容较长具体可点击文末左下角查看原文获取
在生产环境中，建议根据实际的 SQL 多样性和系统内存容量合理配置 instr_unique_sql_count 和 pgstat_track_activity_query_size 参数，以平衡监控精度和内存占用。
第三轮关键提问Dark-Athena: 如果我一条SQL的长度没达到pgstat_track_activity_query_size，也会申请pgstat_track_activity_query_size这个值大小的内存么？
GitHub Copilot: 内容较长具体可点击文末左下角查看原文获取
所以答案是肯定的：即使你的SQL很短（比如SELECT 1;），系统仍然会为每个后端进程的st_activity字段分配完整的pgstat_track_activity_query_size大小的内存空间。
五、结论分析
结合AI的分析，可以得出以下结论：
核心发现
1、固定内存分配
track_activity_query_size是固定会申请的内存大小
占用的内存大小不会由于SQL比这个值小而减小
实际单个unique sql所占用的空间，会比track_activity_query_size还要大一些
当instr_unique_sql_count为GaussDB默认的200000，track_activity_query_size为40960时，unique sql hash table能达到8GB
2、SRF函数特性
SRF函数就是返回多行的函数
dbe_perf.statement里就是一个SRF函数
为了在返回多行时保持数据稳定性，就会把查询结果全存到内存里，直到查询完才释放
3、内存复制机制
dbe_perf.statement查的就是unique sql hash table的内容
SRF为了数据稳定性，几乎把这8GB的内存复制了一份，放到了SRF multi-call context里
深层问题探究
看上去这就是个非常低级的问题？但是问题还没完：
为什么unique sql会那么快达到200000个？
这个环境才刚部署没几天，而且都是跑的存储过程，没有什么拼接SQL，理论上SQL数是稳定有限的。
通过截取statement.query前200个字符进行group by计数排序，发现很大一部分SQL都是一个declare开头的自治事务匿名块。
根本原因
由于我之前和openGauss社区的研发一起分析过plsql编译依赖这个功能的问题，当时为了解决编译时数据字典表锁释放的问题，我提出了可以起个自治事务去编译，这样能避免长时间持有元数据锁的问题。而GaussDB也是用的这个方案（巧合？）。
所以我一眼就看出来GaussDB里记录的这些SQL是在做存储过程编译，但是GaussDB把整个存储过程的内容都放到这个匿名块里了，而且还有一些oid信息，因此必然是不同的SQL。
这个匿名块还会做一些数据字典的DML操作，这些DML的SQL是固定不变的，大概有6~7条。再来就是dbe_perf.statement里，对于parent_unique_sql_id不同的同一个unique_sql_id，会视为不同的记录。
问题链条完整梳理
存储过程编译 ：每次改一个存储过程，就在dbe_perf.statement里生成了约10条的记录
重复生成 ：反复改就反复生成，有时候全量存储过程重建，数字唰唰唰就涨上去了
资源耗尽 ：200000也经不起这么耗，真正的业务SQL可能还会计不进去了
内存占用：全是存储过程编译时自动产生的这些SQL
目前客户这边只能先调小track_activity_query_size到4K，让dbe_perf.statement的内存占得小些，至少让业务测试能继续进行下去。
六、复现方法
诊断了这么多天的问题，弄清楚原理后，非常容易复现unique sql hash table和SRF multi-call context申请大量内存的现象：
环境配置
-- 这个是单个会话的unique sql上限，由于模拟测试都在一个会话里，所以要调大
XML
gs_guc reload -c "track_stmt_session_slot=200000"-- 直接设置到最大值，内存涨得最快
XML
gs_guc reload -c "track_activity_query_size=102400"-- 重启，释放 unique sql 内存
cs
gs_ctl restart测试脚本
-- 构造不同的SQL
-- 注意GaussDB对于表别名或字段别名不同、常量不同的也会进行归一化
-- 所以这里直接用不同的对象名
XML
DECLARE
x_sql1 text;
x_sql2 text;
i int;
BEGIN
FOR i IN1..5000
LOOP
x_sql1 := 'CREATE TABLE t_abcd'||i||'(a int);';
x_sql2 := 'DROPTABLE t_abcd'||i;
EXECUTE IMMEDIATE x_sql1;
EXECUTE IMMEDIATE x_sql2;
END LOOP;
RAISE NOTICE '%', x_sql1;
END;
/验证结果
-- 查询动态共享内存里unique sql hash table的大小
sql
SELECT
contextname,
count(1),
ROUND(sum(totalsize)/1024/1024,2) AS TOTALSIZE_MB,
ROUND(Sum(usedsize)/1024/1024) AS usedsize_MB
FROM GS_shared_MEMORY_DETAIL
GROUPBY contextname
ORDERBY3DESC
LIMIT10;|---------------------------|-------|--------------|-------------|
| contextname | count | totalsize_mb | usedsize_mb |
| unique sql hash table | 1 | 1468.75 | 1469 |
| DefaultTopMemoryContext | 1 | 172.57 | 60 |
| ASP unique sql hash table | 1 | 82.11 | 82 |
| ... | ... | ... | ... |
unique sql hash table占1个多GB
-- 查询SQL实际长度所占的空间，和按track_activity_query_size的长度计算的空间
sql
SELECT
sum(lengthb(query))/1024/1024AS actual_size_mb,
(count(1)*current_setting('track_activity_query_size')::int)/1024/1024AS allocated_size_mb
FROM dbe_perf.statement;|----------------|-------------------|
| actual_size_mb | allocated_size_mb |
| 0.38 | 1401.07 |
按track_activity_query_size来算，也是1个多GB。
日志验证
执行查询后，日志中出现SRF multi-call context：
2025-07-25 10:00:01.523 primary admin postgres 172.17.0.1 140216907527936 12[0:0#0] 0 Mogeaver 23.3.1 - SQLEditor <Script-22.sql> 00000 31806672368306287 [BACKEND] LOG: 00000: unique_sql_id=3740540431, Current SQL is consuming about 1099 MB, allocating 102921000 bytes, memctx:SRF multi-call context, appname:, user_id: 16616, current query is: select sum( lengthb(query) )/?/?,(count(?)*current_setting(?)::int)/?/? from dbe_perf.statement
2025-07-25 10:00:01.523 primary admin postgres 172.17.0.1 140216907527936 12[0:0#0] 0 Mogeaver 23.3.1 - SQLEditor <Script-22.sql> 00000 31806672368306287 [BACKEND] LOCATION: mmgr_memory_check_reach_one_gb, framework_memory_memctrl_util.cpp:241
2025-07-25 10:00:01.523 primary admin postgres 172.17.0.1 140216907527936 12[0:0#0] 0 Mogeaver 23.3.1 - SQLEditor <Script-22.sql> 00000 31806672368306287 [INSTR] LOG: 00000: [UniqueSQL] idx[10] - new memory allocated: 102921000
2025-07-25 10:00:01.523 primary admin postgres 172.17.0.1 140216907527936 12[0:0#0] 0 Mogeaver 23.3.1 - SQLEditor <Script-22.sql> 00000 31806672368306287 [INSTR] LOCATION: unique_sql_log_result_mem, instr_unique_sql.cpp:1407
2025-07-25 10:00:01.524 primary admin postgres 172.17.0.1 140216907527936 12[0:0#0] 0 Mogeaver 23.3.1 - SQLEditor <Script-22.sql> 00000 31806672368306287 [INSTR] LOG: 00000: [UniqueSQL] total memory allocated: 1132131000
2025-07-25 10:00:01.524 primary admin postgres 172.17.0.1 140216907527936 12[0:0#0] 0 Mogeaver 23.3.1 - SQLEditor <Script-22.sql> 00000 31806672368306287 [INSTR] LOCATION: unique_sql_log_result_mem, instr_unique_sql.cpp:1408
七、总结-经验教训
1、经验的积累非常重要
国产数据库使用过程中肯定会发现很多新问题，其中有一些综合性的问题，原厂的内核研发都不一定能找到原因，具备综合技能的DBA能从现场的蛛丝马迹结合长期的工作经验所产生的直觉，来发现问题症结所在
2、知识的积累非常重要
如果连内存区域都分不清，就算数据库已经提供了很多方法来进行诊断，面对本文这个问题，脑子里只能是一团浆糊
3、需要学会借助AI
现在的AI有了agent，能自动且快速完成很多事，本文中就让AI自动翻源码分析，对问题进行了快速定位