Linux Dolphin内存占用高怎么办

Linux 上 DolphinDB 内存占用高的排查与优化

一、先快速定位占用来源

• 查看节点级内存与配置上限：使用 getMemLimitOfQueryResult()、license().maxMemoryPerNode、getConfig(`maxMemSize) 确认许可证、配置与单次查询结果上限；若机器内存为 16GB 且仅部署 1 个节点，建议将 maxMemSize 设为约 12GB（通常不超过物理内存的 80%–90%）。
• 查看会话与对象占用：用 getSessionMemoryStat() 找出占用高的 sessionId，必要时用 closeSessions(sessionId) 终止；用 objs() / objs(true) 列出节点变量，非共享变量用 undef，共享表用 undef(“sharedTable”, SHARED) 释放。
• 查看缓存与引擎占用：结合 clearAllCache() / flushOLAPCache() / flushTSDBCache() 等清理函数与对应缓存类型，定位 OLAP/TSDB CacheEngine、维度表缓存 等是否异常增长。
• 检查后台任务：用 getRecentJobs() / getConsoleJobs() 发现长时任务，必要时 cancelJob / cancelConsoleJob 中止。
• 判断是否被系统 OOM Killer 终止：执行 dmesg -T | grep -i “out of memory|killed process”，若出现 “Out of memory: Kill process … dolphindb”，说明被内核回收，需要下调 maxMemSize 或优化查询/分区。
• 客户端侧排查：GUI/前端执行 **select *** 容易把全分区列拉入客户端内存，建议改为 **t = select …; select top 1000 *** 或只查需要的列。

二、立刻缓解与兜底措施

• 释放缓存与对象：在业务低峰执行 clearAllCache()；针对具体缓存引擎执行 flushOLAPCache() / flushTSDBCache()；会话或共享对象用 undef / undef(“sharedTable”, SHARED) 释放；必要时 closeSessions() 终止异常会话。
• 限流与降级单次查询：用 setMemLimitOfQueryResult(N) 降低单次查询内存上限，避免大结果一次性拉满内存。
• 控制 OS 资源：检查 ulimit -a（如 max memory size、virtual memory），确保进程可用内存与地址空间足够；避免同机部署过多重内存进程。
• 设置节点内存红线：在 dolphindb.cfg / cluster.cfg 合理设置 maxMemSize，通常取物理内存的 80%–90%；若许可证上限更低，以许可证为准。
• 避免触发 OOM Killer：一旦出现被系统杀死的日志，优先降低 maxMemSize、优化大查询与分区设计，并减少同机内存竞争。

三、SQL 与分区层面的根治方案

• 分区裁剪与列裁剪：查询务必带上分区列过滤并将分区条件前置；避免 **select ***，只查需要的列，减少不必要列加载。
• 分区粒度设计：单分区未压缩数据量建议 100MB–1GB；按经验公式控制分区解压后在内存的大小不超过 S/8W（S 为节点可用内存、W 为 worker 数），如 32GB/8 核 ≈ 512MB/分区，避免过大或过小。
• 均匀分区与复合分区：避免热点分区与数据倾斜；必要时采用 COMPO（如日期值分区 + 代码范围分区）提升并行度与均衡性。
• 大结果集处理：分页/分块拉取（如 top N、分批聚合），避免一次性返回超大结果；必要时在查询侧做聚合/抽样后再回传。

四、配置与运维建议

• 许可证与上限对齐：用 license().maxMemoryPerNode 与 getConfig(`maxMemSize) 核对上限，避免配置超过许可证或物理内存的 90%。
• 流计算与缓存：合理设置 流数据缓存容量（capacity） 与发布/订阅队列，避免消息堆积导致内存飙升。
• 插件与外部组件：插件异常也会放大内存占用，检查日志中 “[xx plugin], Out of memory”；自定义插件需严格管理内存与释放策略。
• 监控与告警：持续关注 session 内存、缓存命中、作业运行时长，对异常增长设置阈值告警并联动清理/限流。
• 避免误用维度表：维度表应小而精；若数据量大，改为分区表并按需加载。

五、常见场景与对应操作清单