关于RabbitMQ性能问题的几点分析

目前对RabbitMQ的使用才刚刚开始,下面提出的问题,也许是由于对服务器的配置或者对客户端API还不了解导致的。欢迎斧正。

一. 要避免流控机制触发

  • 服务端默认配置是当内存使用达到40%,磁盘空闲空间小于50M,即启动内存报警,磁盘报警;报警后服务端触发流控(flow control)机制。一般地,当发布端发送消息速度快于订阅端消费消息的速度时,队列中堆积了大量的消息,导致报警,就会触发流控机制。

  • 触发流控机制后,RabbitMQ服务端接收发布来的消息会变慢,使得进入队列的消息减少;与此同时RabbitMQ服务端的消息推送也会受到极大的影响,测试发现,服务端推送消息的频率会大幅下降,等待下一次推送的时间,有时等1分钟,有时5分钟,甚至30分钟。

  • 一旦触发流控,将导致RabbitMQ服务端性能恶化,推送消息也会变得非常缓慢;因此要做好数据设计,使得发送速率和接收速率保持平衡,而不至于引起服务器堆积大量消息,进而引发流控。通过增加服务器集群节点,增加消费者,来避免流控发生,治标不治本,而且成本高。

第一次修改本节

  • 服务器单节点,单网卡全双工情况下,测试发现发布速度过快,压满发布PC机带宽,对于服务器来说,下行(接收)带宽也会压满,可是上行(转发递送)带宽却出现了明显的下降,似乎有一个争抢。这可能是导致触发流控的原因。

二. 从底层取数据一定要非常及时

  • 订阅端每隔500MS调用一次amqp_consume_message接口函数从socket上获取数据,正常情况下,服务器每次会推送几百条消息,而且推送的频率会比较高;导致订阅端的本机socket缓冲区会很快存满,导致很多消息无法进行缓存,而被丢掉。

  • 测试发现(单线程订阅):

用例 发布消息条数 调用amqp_comsume_message间隔(MS) 实际接收条数
1 630 500 269
2 695 470 269
3 513 460 513
4 503 450 503

三. 消息大小不要超过4MB

  • 客户端与RabbitMQ服务端的最大帧是128K,但消息大小却可支持数MB,这是可能是因为底层做了拆包组包的,目前我还未查看底层代码。

  • 用线程来模拟50个发布者和50个订阅者;消息包大小由1K到10MB,当包大小达到4.5MB时,服务器的性能出现明显的异常,传输率尤其是每秒订阅消息的数量,出现波动,不稳定;同时有一部分订阅者的TCP连接出现断开的现象。可能是客户端底层或者RabbitMQ服务端在进行拆包,组包的时候,出现了明显的压力,而导致异常的发生。

  • 超过4MB的消息,最好先进行分包。

第一次修改本节

  • 由于用线程模拟大量发布者,且是服务器单节点,受客户端主机网卡的限制,发布线程没有速度控制,导致有大量数据发送,服务器带宽下行速率也满负荷,上行带宽却明显低于下行速率,导致服务器内存有大量消息堆积,进而触发RabbitMQ服务器paging操作,才出现了上述不稳定和订阅者断开现象。对发布端做适当流量控制,断开连接现象不再出现,但每秒消息数仍然不稳定。

你可能感兴趣的:(RabbitMQ)