OOM排查之路：一次曲折的线上故障复盘

主要观点总结

本文旨在分享关于服务整合中遇到的内存溢出问题的排查经历，并介绍了在排查过程中使用的工具和排查思路。

关键观点总结

关键观点1: 问题的发现与解决

服务整合了Paimon数据湖与RocksDB，通过SDK负责数据的查询与写入。系统在线上环境连续发生了三次内存溢出（OOM）故障。经过曲折的排查过程，最终成功定位并解决问题。

关键观点2: 第一次OOM现象及解决

某天早上，收到服务的线上告警，发现大量RPC请求失败，登录相关平台发现所有对外RPC服务都下线了。经过调查，发现是Paimon表的数量和bucket数量不匹配导致的问题。决定减少bucket数量，并根据公式设置为2的次方个bucket，修复后线程数降到了理想范围，解决了问题。

关键观点3: 第二次OOM现象及排查

上次问题解决后，加强了服务的相关告警。然而时隔20多天后，再次发生OOM。通过监控发现内存利用率上涨，但不是突增。通过排除Java线程数量增长导致的OOM可能性，最终通过NMT工具和async-profiler分析发现RocksDB的JNI分配内存问题。

关键观点4: 第三次OOM现象及解决

观察到线上机器的内存利用率不断上涨，通过控制变量法，再次将问题锁定在SDK上。经过详细排查，发现RocksDB使用JNI分配内存但无法释放的问题。最终决定转换写Paimon的方式，从通过自己的应用写转换为应用发送消息通过Flink写Paimon。

关键观点5: 排查工具介绍

在排查问题的过程中，使用了MAT、NMT、Arthas、async-profiler等工具和linux指令。这些工具帮助定位内存泄漏的根源，分析应用在特定时刻的内存消耗详情。

关键观点6: 排查思路总结

面对内存问题，首先要保留现场或复现问题。使用监控工具初步定位问题，再使用相关工具进行分析。阅读文章、请教专家、总结问题记录心得也是排查问题的关键步骤。

免责声明