RabbitMq 最全的性能调优笔记

最新推荐文章于 2025-07-20 09:08:10 发布

转载

最新推荐文章于 2025-07-20 09:08:10 发布 · 8.9k 阅读

CC 4.0 BY-SA版权

原文链接：https://segmentfault.com/a/1190000016351345

文章标签：

本文详细介绍了RabbitMQ的性能调优要点，包括避免流控机制触发、消息大小限制、consume预取参数影响、磁盘瓶颈及队列管理。通过参数调整、模式选择、持久化策略等方式提升RabbitMQ的性能，并提供了问题分析和解决方案。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

RabbitMq 性能调优笔记

[TOC]

服务端默认配置是当内存使用达到40%，磁盘空闲空间小于50M，即启动内存报警，磁盘报警；报警后服务端触发流控（flowcontrol）机制。
一般地，当发布端发送消息速度快于订阅端消费消息的速度时，队列中堆积了大量的消息，导致报警，就会触发流控机制。
触发流控机制后，RabbitMQ服务端接收发布来的消息会变慢，使得进入队列的消息减少；
与此同时RabbitMQ服务端的消息推送也会受到极大的影响，测试发现，服务端推送消息的频率会大幅下降，等待下一次推送的时间，有时等1分钟，有时5分钟，甚至30分钟。
一旦触发流控，将导致RabbitMQ服务端性能恶化，推送消息也会变得非常缓慢；
因此要做好数据设计，使得发送速率和接收速率保持平衡，而不至于引起服务器堆积大量消息，进而引发流控。通过增加服务器集群节点，增加消费者，来避免流控发生，治标不治本，而且成本高。
服务器单节点，单网卡全双工情况下，测试发现发布速度过快，压满发布PC机带宽，对于服务器来说，下行（接收）带宽也会压满，可是上行（转发递送）带宽却出现了明显的下降，似乎有一个争抢。这可能是导致触发流控的原因。

订阅端每隔500MS调用一次amqp_consume_message接口函数从socket上获取数据，正常情况下，服务器每次会推送几百条消息，而且推送的频率会比较高；

导致订阅端的本机socket缓冲区会很快存满，导致很多消息无法进行缓存，而被丢掉；

发布消息条数	调用amqp_comsume_messag

200万优质内容无限畅学