【达梦数据库】OOM问题排查思路

背景

近期遇到很多OOM的问题，一部分是数据库申请内存过大导致OOM，另一部分是因为系统本身OOM，做以下总结。

问题1：DM线程导致OOM

问题现象

数据库服务异常停止。linux下，查看系统日志/var/log/messages，查找oom-killer关键字，定位到DM线程导致OOM。

vim /var/log/messages

排查思路

1、查看数据库日志

日志目录下查看log日志：

 vim /home/dmdba/dmdbms/log/dm_DMDB_202506.log

无ERROR、FATAL，且对应时间点日志未报错。

2、查看数据库参数是否合理

内存参数

查看dm.ini文件中，内存参数是否合理。

vim /dmdata/DAMENG/dm.ini

通常来说，如果全部内存的80%给到数据库使用，BUFFER差不多是总内存的1/3（如果比例更低，BUFFER也会相应的更低，可以灵活调节），以下是根据自动优化脚本计算出的参数的推荐值：

会话参数

查看dm.ini文件中，会话参数MAX_SESSIONS是否合理。

vim /dmdata/DAMENG/dm.ini

会话会占用内存，过多的会话容易导致OOM，如果V$SESSIONS视图中的会话数接近最大会话数MAX_SESSIONS，且远远大于优化脚本中的推荐值，那需要小心了，建议还是加大内存重新优化;

SELECT * FROM V$SESSIONS;

3、查看Core文件是否生成

查看Core文件配置路径

cat /etc/sysctl.conf

查看生成的Core文件

ll /dmdata/

如果有Core文件产生，可以通过gdb工具分析Core文件，并获取到异常SQL，进行复现。相关操作请参考链接: 【达梦数据库】Coredump文件生成与分析

4、特殊情况

若以上情况都没有问题，即日志不产生报错、参数配置合理、未产生Core文件
，可以限制一下会话数的问题大小，待应用运行后如果占用大内存的SQL会报错，这样可以反向定位到问题SQL。

--动态参数
SP_SET_PARA_VALUE(1,'MAX_SESSION_MEMORY',2048);
--静态单数
SP_SET_PARA_VALUE(1,'MAX_HEAP_SIZE',2048);

问题2：非DM线程导致OOM

可以根据DM线程导致OOM的思路排查一下：

• 如果数据库日志中对应时间点日志未报错，大概率不是数据库的问题，需要服务器厂商排查一下。