WSO2 EI 6.4.0 Docker容器ETL过程中GC开销超限内存问题排查

一、代码层面的内存泄漏排查点 #

• BigQuery连接器数据加载逻辑：检查runQuery操作是否一次性将全量查询结果加载到EI内存中。默认部分连接器会拉取完整结果集，当数据量超8000条时，大体积结果对象会持续占用堆内存，若未及时回收易引发泄漏。
• 迭代中介器的资源残留：确认迭代中介器（Iterate Mediator）是否配置preservePayload="false"，若保留原始大Payload，会导致内存中同时存在原始数据集和每条迭代的子消息，大幅增加内存占用。
• MessageContext属性管理：排查序列中是否将大量数据存储到MessageContext的全局/持久化属性中，这些属性会伴随上下文生命周期存在，未及时移除会累积占用内存。
• 未释放的资源：检查BigQuery连接、ResultSet等资源是否在使用后正确关闭，未释放的资源会被JVM视为活跃对象无法回收，长期运行会导致内存泄漏。

二、内存问题的具体解决方法 #

• 流式分页获取BigQuery数据：修改BigQuery连接器配置，启用分页查询，每次拉取固定条数（如1000条）的结果，处理完当前页后再请求下一页，避免一次性加载全量数据到内存。
• 优化迭代中介器配置：在迭代中介器中设置preservePayload="false"，并在每条记录处理完成后添加<removePayload/>中介器清理当前消息，减少内存中留存的消息对象。
• 批量调用DSS服务：如果目标DSS支持批量插入，将多条记录打包为一个请求发送，避免逐条调用产生大量请求对象和HTTP连接开销，同时降低内存占用。
• 调整JVM GC参数：在Java 1.8.0_171环境下，启用G1垃圾收集器，添加参数：-XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:+ParallelRefProcEnabled，提升内存回收效率；同时调整-XX:NewRatio=2优化新生代与老年代比例，减少老年代内存积压。
• 清理MessageContext冗余属性：在序列中处理完每条记录后，使用<property name="XXX" scope="default" action="remove"/>移除不必要的属性，避免上下文内存占用累积。
• 任务并发控制：在任务调度器配置中添加concurrent="false"，防止Cron表达式触发的任务重叠执行，避免多个任务同时加载数据导致内存叠加。
• 分析堆转储文件：利用MAT（Memory Analyzer Tool）分析已生成的heap-dump.hprof，定位占用内存最高的对象类型，确认是数据加载过大还是资源泄漏导致的OOM，针对性优化。

内容的提问来源于stack exchange，提问作者Justin