FIWARE Orion接收/op/notify通知时内存占用过高问题咨询

问题场景 #

• 部署环境：k3s集群，采用HPA模式的Orion，连接副本集模式MongoDB
• 核心问题：联邦模式下主集群向二级集群发送通知时，二级集群的Orion Broker内存持续升高，最终触发OOMKilled导致Pod重启；即使少量通知也会引发该问题，内存占用呈持续上升趋势
• 细节补充：
  • 仅在接收/op/notify端点的通知时出现该问题，通知数量越多，内存增长越明显
  • 停止主集群的通知流后，Orion可正常处理各类CRUD操作
  • 日志中无任何异常或错误信息
  • Orion 4.0版本与3.11版本均存在该问题
• 已尝试方案：增加Orion Pod数量仅能减少重启频率，无法解决内存持续增长的根本问题

咨询问题解答 #

1. 是否可通过Orion配置解决该内存占用问题？ #

可以通过调整Orion的核心配置参数缓解内存增长，推荐尝试以下配置：

• NOTIFY_MAX_QUEUE_SIZE：限制通知处理队列的最大长度，避免队列无限堆积占用内存。建议设置为1000左右，超出队列上限时可通过NOTIFY_ON_OVERFLOW配置溢出行为（如拒绝新通知）
• NOTIFY_THREADS：控制处理通知的线程数量，避免过多线程同时运行导致内存占用过高。根据Pod资源配置调整，例如设置为4或8
• DB_POLL_SIZE：调整MongoDB连接池大小，避免过多连接占用内存。建议根据Pod内存限制设置为10-20
• MEMORY_MONITOR（仅Orion 4.x支持）：启用内存监控，配置MEMORY_MONITOR=1并设置MEMORY_LIMIT为容器内存限制的90%，触发阈值时自动清理内存或触发重启（需结合HPA使用）

2. 是否为Orion的异常行为？若为是，是否有已知修复方案或规避措施？ #

这属于Orion的已知内存泄漏异常行为，主要集中在/op/notify端点的通知处理流程中，尤其是联邦模式下跨集群通知场景。针对该问题的处理方式如下：

• 官方修复方案：升级至Orion 4.1及以上版本，官方在该版本中优化了通知处理的内存管理逻辑，修复了多处相关内存泄漏问题
• 版本规避措施（针对3.11和4.0版本）：
  • 启用通知批量处理：配置NOTIFY_BATCH_SIZE（如50）和NOTIFY_BATCH_TIMEOUT（如1000），将多个通知合并处理，减少内存频繁分配与释放
  • 调整Pod资源与HPA配置：临时提升Pod内存配额，同时调低HPA的CPU/内存触发阈值，提前扩容Pod以避免OOM
  • 配置存活探针自动重启：通过Kubernetes的livenessProbe设置内存使用率阈值（如90%），当内存占用超过阈值时自动重启Pod，替代被动的OOMKilled重启

内容的提问来源于stack exchange，提问作者Fabio Henrique Cabrini