【 使用环境 】生产环境 or 测试环境
【 OB or 其他组件 】
4.2.1.0
【 使用版本 】
4.2.1.0
【问题描述】清晰明确描述问题
查了一下其他的4013问答，还是没能解决问题，下面图片为__all_virtual_memory_info的hold排序，PLtemp模块我不缺算不算大，另外也不知道这个模块是干什么的
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：
【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！
根据您的描述，您在使用 OceanBase 4.2.1.0 版本的过程中遇到了内存不足的错误 (-4013)，尤其是在执行造数脚本大约 10 分钟后出现了这个问题，并且您特别关注 PLTemp 模块的内存占用情况。
针对您遇到的问题，我建议使用 obdiag 工具来采集相关的日志信息，并进行进一步的分析。首先，我们可以从内存问题的角度出发，使用 obdiag 来采集与内存相关的日志信息。
由于当前 obdiag 的根因分析功能中并没有直接针对内存不足错误 (-4013) 的特定场景，因此这里我们先进行日志采集。
内存问题
obdiag gather scene run --scene=observer.memory
该命令会帮助您收集与内存问题相关的日志信息，包括但不限于系统内存使用情况、OceanBase 进程的内存使用情况等。
请您执行上述命令并提供采集到的日志压缩包，这将有助于我们更准确地定位问题所在。
附上敏捷诊断工具 obdiag 使用帮助链接
集群啥配置，造多少数啊，怎么造的
如果实在是内存太少，得适当扩
集群三台机器内存都是64G，造数500条记录commit一次，造数到一万多条就报错了，内存应该是够了啊，配置租户内存应该是四五十个G
再向您确认几个问题:
1.没有设置
2.在造数的时候同时还有其他应用在使用，不单纯在造数，不过不造数的时候不会爆内存不足
3.这个暂时无法提供，脚本简单，只是insert 500commit一次
4.错误ri日志在内网，无法导出
根据您提供的日志信息，可以看出在造数过程中确实出现了内存不足的错误 (-4013)。错误发生在解析 SQL 语句的过程中，具体是在解析 WHERE 子句时触发了内存不足的错误。此外，日志中还出现了其他一些错误，如 -4016，这些错误可能与内存不足有关，也可能是因为其他原因导致的。
SELECT * FROM __all_tenant WHERE tenant_id = 500;
__all_virtual_memory_info 视图来监控内存使用情况，特别是 PLTemp 模块的内存使用情况。如果发现 PLTemp 模块的内存使用异常高，可能需要进一步调查造数脚本中是否存在复杂的存储过程或动态 SQL。ob_sql_work_area_percentage 和 ob_sql_work_area_min_size 等，这些参数会影响 SQL 执行时的内存分配。obdiag 工具来收集更多的诊断信息，特别是内存使用情况和系统配置方面的信息。这可以帮助进一步定位问题。__all_virtual_memory_info 视图，特别是在造数过程中，注意观察 PLTemp 模块的内存使用情况。obdiag gather scene run --scene=observer.memory 来收集更多的诊断信息。如果您按照以上步骤操作后仍然遇到问题，请提供更多的诊断信息，我们将继续协助您解决问题。
具体信息可参考以下文档:
(小助手的答复已结束，如未能解决您的问题，请继续提问并等待其他同学的回复，谢谢！)
4013内存排查
查看模块内存： select * from gv$ob_memory where tenant_id=500 order by used desc limit 20;
–上面查询的svr_ip和mod_name
根据ip和模块查看模块信息：select * from __all_virtual_malloc_sample_info where svr_ip=‘10.10.10.147’ and mod_name=‘glibc_malloc’ order by alloc_bytes desc limit；
您好，上午在解决这个问题的时候，按照下面的资料改过转储线程数，现在报错，恢复成0还是报错，请问这个怎么解决，目前复现不出内存爆满的情况
https://www.oceanbase.com/docs/common-oceanbase-database-cn-10000000001579565
你调整了minor_merge_concurrency然后又恢复了默认值0，现在OB集群起来了吗？如果没有起来，麻烦发下observer.log，你这里的报错日志应该是应用报错日志
是的，4.x的参数应该是compaction_high_thread_score，改成2后发现报错恢复成0看，OB还没有重启，因为机器在内网，没有办法把整个日志文件拿出来，请问截图可以吗，有什么关键字搜索
你重启下，如果有问题，将observer.log的报错截图发出来也可以，可以搜下error看下
另外你4013的报错日志也不全，可以通过如下方式发下日志：
1.开启 Trace 功能
SET ob_enable_show_trace=ON;
2.执行SQL
3.获取SQL trace_id
SELECT last_trace_id() FROM DUAL;
4.登录对应 OBServer 节点，进入到日志文件所在目录
cd /home/admin/oceanbase/log
5.获取trace_id对应的日志
grep xxxxxxx observer.log --填写第3步获取的trace_id
500租户内存使用
select /* MONITOR_AGENT */ sum(hold)/1024/1024/1024 as hold, sum(used)/1024/1024/1024 as used from GV$OB_MEMORY where tenant_id = 500 and mod_name <> ‘OB_KVSTORE_CACHE_MB’;
select zone,concat(SVR_IP,’:’,SVR_PORT) observer,
cpu_capacity_max cpu_total,cpu_assigned_max cpu_assigned,
cpu_capacity-cpu_assigned_max as cpu_free,
round(memory_limit/1024/1024/1024,2) as memory_total,
round((memory_limit-mem_capacity)/1024/1024/1024,2) as system_memory,
round(mem_assigned/1024/1024/1024,2) as mem_assigned,
round((mem_capacity-mem_assigned)/1024/1024/1024,2) as memory_free,
round(log_disk_capacity/1024/1024/1024,2) as log_disk_capacity,
round(log_disk_assigned/1024/1024/1024,2) as log_disk_assigned,
round((log_disk_capacity-log_disk_assigned)/1024/1024/1024,2) as log_disk_free,
round((data_disk_capacity/1024/1024/1024),2) as data_disk,
round((data_disk_in_use/1024/1024/1024),2) as data_disk_used,
round((data_disk_capacity-data_disk_in_use)/1024/1024/1024,2) as data_disk_free
from oceanbase.gv$ob_servers;
show parameters where name in (‘memory_limit’,‘memory_limit_percentage’,‘system_memory’,‘log_disk_size’,‘log_disk_percentage’,‘datafile_size’,‘datafile_disk_percentage’);
获取租户的内存元信息（limit、hold、cache_hold）看下
grep ‘malloc_allocator.*tenant: 1004’ observer.log -A 20
这个获取trace_id可以通过observer.log查找4013里面的日志获取吗，因为不只是造数脚本在使用数据库，且不是每一次sql都是4013，这个last_trace_id查找的可能不是想要的数据
你继续查下 1004 租户的DEFAULT_CTX_ID的内存元信息（hold、used、limit、内存碎片清理信息）
grep ‘1004 ctx_id= DEFAULT_CTX_ID’ observer.log -C 1 -A 10
