Mercure项目内存泄漏问题深度分析与解决方案

问题背景

Mercure作为一个实时通信服务，近期版本出现了严重的内存泄漏问题。该问题表现为随着运行时间增长，内存使用量持续上升，最终导致服务无响应。特别是在高并发场景下（超过1万并发连接），问题尤为明显。

问题现象

根据用户报告和性能分析数据，可以观察到以下典型现象：

1. 内存使用量随时间持续增长，最终耗尽系统内存
2. 服务在高负载下会停止响应发布命令
3. 系统不使用SWAP空间，直接耗尽物理内存
4. 平均响应时间在内存满载时可延长至3分钟

技术分析

缓存配置问题

最初怀疑是LRU缓存配置不当导致的问题。Mercure支持通过lru_cache指令配置缓存大小，但文档中的示例值7e8 1e9实际上是错误的格式，会导致解析失败。

更深入的分析发现：

1. 当前版本的lru_cache只接受一个参数（每个分片的项目数），默认值为1e4
2. 256个分片的总容量约为256万项目
3. 过大的配置值（如6e8）会导致1500亿项目的容量，远超实际需求

内存泄漏根源

通过pprof内存分析工具获取的堆栈信息显示，主要问题出在订阅者管理部分：

1. handleFullChan函数设置了disconnected标志但不关闭输出通道
2. 这可能导致订阅者保持连接但无法接收消息
3. 同时造成通道泄漏，因为当disconnected设置为1时，Disconnect操作会被跳过

并发处理缺陷

在高并发场景下（10k+连接），系统表现出：

1. Goroutine数量异常增长
2. 内存分配持续增加不释放
3. CPU使用率异常升高
4. 最终导致服务完全停止响应新请求

解决方案

临时解决方案

1. 移除lru_cache配置指令，使用默认值
2. 如需自定义，建议设置为1e5（2560万项目容量）
3. 增加系统资源（16GB内存+8CPU可显著改善情况）

根本解决方案

开发团队已提交修复补丁，主要改进包括：

1. 修正handleFullChan函数的通道关闭逻辑
2. 优化订阅者断开连接的处理流程
3. 完善内存回收机制

性能优化建议

1. 根据实际负载调整缓存大小，避免过大或过小
2. 定期监控内存使用情况和Goroutine数量
3. 在高并发场景下适当增加系统资源
4. 考虑实现自动缩放机制应对流量波动

结论

Mercure的内存泄漏问题主要源于订阅者管理中的资源释放不彻底和缓存配置不当。通过合理配置和代码修复，可以有效解决这一问题。对于高负载生产环境，建议密切监控系统指标并及时调整配置参数。

该问题的解决不仅提升了Mercure的稳定性，也为其他实时通信系统的内存管理提供了有价值的参考案例。开发团队应继续加强性能测试和压力测试，确保类似问题在早期就能被发现和解决。