Java heap space
OOM Killer
ChunkCacheEngine is out of memory, possibly due to a transaction that tries to write data larger than the available memory
C++:std::bad_alloc
Failed to merge results of partitioned calls: Failed to append data to column 'ETFSellNumber' with error: Out of memory' script: 'select * from pt where date(DateTime) = 2021.12.29;
Out of memory, BlockFileOutputStream failed to alloc memory and will retry.
[xx plugin],Out of memory
Why OOM？
DolphinDB 内部组件：数据量、查询复杂度、并发用户数等因素影响着 DolphinDB 的工作负荷。因此，当用户使用 DolphinDB 处理大规模数据或者执行复杂查询时，内存需求会相应增加，当超出可分配内存后会造成 OOM。 外部组件：外部组件如应用程序（插件）的内存管理策略不当，或 GUI、VSCode 和 API 使用不当，会产生内存未及时释放、内存泄漏、内存分配不合理等问题，进而导致 OOM 的发生。 外部限制：外部限制主要包括 DolphinDB 的许可证限制、DolphinDB 配置文件限制、以及操作系统面临的内存压力。在这类限制条件下，DolphinDB 在执行大规模任务时，可能也会面临内存不足的问题。
故障排查解决方案
诊断内存使用模式
如果发生宕机，首先需要排查是否因为内存耗尽，使得 DolphinDB 进程被操作系统杀掉。查看操作系统日志，可以排查是否触发了 OOM Killer。输入命令：
dmesg -T|grep memory
更新或优化配置
其次，考虑 OOM 是否由于外部限制所导致。
ulimit -a
license().maxMemoryPerNodegetConfig(`maxMemSize)
内部组件排查
除此之外，还可以通过函数 getRecentJobs() 和 getConsoleJobs() 查看是否有超过预期运行时长的后台或交互任务，检验是否做到了合理分区、正确使用 SQL、合理配置流数据缓存区、及时管理 session 变量以及合理写入任务等。
外部组件排查
内存压力可能由于 DolphinDB 内部引擎导致，也可能由于 DolphinDB 进程中运行的某些插件导致，如 Kafka 、MySQL、ODBC 以及 HDFS 插件或者自定义插件等等，插件若设计不佳，容易消耗大量内存，从而导致内存不足错误。
可使用以下方法诊断由插件引起的内存压力：
查看日志。若日志中有此内容：[xx plugin],Out of memory，可以判断是由插件引发的 OOM。如果为官方发布的插件，可以通过点击官网下载页面的社群入口，将问题反馈给工程师。如果是自定义开发插件，需要定位下哪个函数导致的内存使用过高，修改插件源代码，重新编译再加载到 DolphinDB 中。
若 DolphinDB GUI 客户端出现报错：Java heap space，通常情况下是因为 GUI 客户端占用内存过高。可将 SQL 语句
select * from xx
修改为
t = select * from xxselect top 1000 * from xx
从而降低 GUI 客户端内存占用，避免上述问题。
如何规避 OOM
优化服务器以及数据库配置
打开操作系统对进程的资源限制
合理配置 maxMemSize
对自定义插件内存严格管理
合理分区和正确使用 SQL
合理均匀分区
数据查询尽可能使用分区过滤条件
只查询需要的列
合理配置流数据缓存区
合理配置流数据的缓存区
及时管理 session 的变量
及时释放数据量较大的变量
分批次写入数据
避免大事务写入
在使用 DolphinDB 遇到 OOM 时，可以参考本文，定位分析 OOM 的产生原因，并采取方案来解决内存问题。同时，日常使用数据库时注意规划、优化与维护系统，可以在一定程度上规避 OOM 的出现，进一步提高数据库的稳定性。故障排查完整方案请参考阅读原文，使用过程中如有文章未涉及到的情况，请联系 DolphinDB 小助手（dolphindb1），加入技术群交流探讨~
Explore More
扫描二维码，添加 DolphinDB 小助手
