VerneMQ高负载场景下CPU持续增长问题分析与解决方案

问题现象

在VerneMQ 1.13.0版本的生产环境中，当连接数达到约12000个客户端时，系统出现了CPU使用率持续增长的现象。这种增长呈现以下特征：

1. CPU使用率缓慢上升，持续数天后突然出现峰值，最终导致服务不可用
2. 系统reduction计数呈指数级增长，与CPU增长趋势一致
3. 进程监控显示大量ets_select和gen_server操作占用CPU资源
4. ETS内存有小幅增长，但相对于总内存量影响不大

深入分析

通过技术团队的分析和测试，发现问题的根源与Lua脚本的使用方式密切相关。具体表现为：

1. 不必要的消息级ACL检查：系统在auth_on_publish钩子中实现了自定义的ACL检查逻辑，这导致了每个消息发布时都会执行Lua脚本验证

2. Lua层性能瓶颈：在高消息吞吐量下，Lua脚本的执行成为了系统瓶颈，表现为：

   • 大量ETS表查询操作
   • 系统reduction计数异常增长
   • 最终导致CPU使用率持续上升

3. 配置误区：团队最初没有意识到VerneMQ的ACL缓存机制已经能够满足需求，额外添加的消息级ACL检查实际上是不必要的

解决方案

经过验证，采取以下措施有效解决了问题：

1. 移除冗余ACL检查：取消自定义的auth_on_publish钩子实现，利用VerneMQ内置的ACL缓存机制

2. 优化MQTT 5.0配置：针对MQTT 5.0会话设置合理的窗口大小限制：

   receive_max_client = 20000
   receive_max_broker = 20000
   

3. 系统参数调优：确保操作系统层面的文件描述符限制和连接状态监控正常

技术原理

1. VerneMQ ACL机制：系统在auth_on_register阶段就会将ACL规则加载到缓存中，后续的消息发布和订阅检查直接使用Erlang层面的缓存，无需每次调用Lua脚本

2. Lua执行模型：VerneMQ的Lua脚本执行受num_states参数控制，不当的并发设置可能导致性能问题

3. MQTT协议版本差异：MQTT 3.1.1和5.0在流控机制上有显著区别，需要分别配置max_inflight_messages和receive_max参数

最佳实践建议

1. 谨慎使用消息级ACL：除非有特殊需求，否则应避免在消息发布/订阅层面实现ACL检查

2. 合理配置Lua环境：根据实际负载调整num_states等Lua相关参数

3. 协议版本适配：明确区分MQTT不同版本的配置要求

4. 监控指标关注：定期检查系统reduction计数、ETS操作等关键指标

总结

这次问题排查揭示了VerneMQ在高负载场景下的一个重要性能优化点：合理使用其内置的ACL缓存机制可以显著降低系统开销。对于需要实现复杂ACL逻辑的场景，建议：

1. 优先考虑在注册阶段完成主要ACL检查
2. 如确实需要消息级控制，考虑开发原生Erlang插件而非Lua脚本
3. 进行充分的性能测试验证方案可行性

通过这次优化，系统在保持12000+连接的同时，CPU使用率恢复稳定，验证了解决方案的有效性。