RabbitMq 最全的性能调优笔记 - SegmentFault 思否

> 本文由 [简悦 SimpRead](http://ksria.com/simpread/) 转码， 原文地址 [segmentfault.com](https://segmentfault.com/a/1190000016351345)

RabbitMq 性能调优笔记
===============

[TOC]

避免雷区
----

### 要避免流控机制触发

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

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

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

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

<table><thead><tr><th>发布消息条数</th><th>调用 amqp_comsume_message 间隔 (MS)</th><th>实际接收条数</th></tr></thead><tbody><tr><td>630</td><td>500</td><td>269</td></tr><tr><td>695</td><td>470</td><td>269</td></tr><tr><td>513</td><td>460</td><td>269</td></tr><tr><td>503</td><td>450</td><td>503</td></tr></tbody></table>

### 消息大小不要超过 4MB

*   客户端与 RabbitMQ 服务端的最大帧是 128K，但消息大小却可支持数 MB，这是可能是因为底层做了拆包组包的，目前我还未查看底层代码。
*   用线程来模拟 50 个发布者和 50 个订阅者；

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

*   **超过 4MB 的消息，最好先进行分包**

### consume 时预取参数的大小对 consume 性能影响很大

具体可参见[官方博客](http://www.rabbitmq.com/blog/2012/05/11/some-queuing-theory-throughput-latency-and-bandwidth/)

### 磁盘也可能形成瓶颈

磁盘也可能形成瓶颈，如果单台机器队列很多，确认只在必要时才使用 duration(持久化)，避免把磁盘跑满；

### 队列的消息大量累积后

队列的消息大量累积后，发送和消费速度都会受到影响，导致服务进一步恶化，采用的方法是，额外的脚本监控每个队列的消息数，超过限额会执行 purge 操作，简单粗暴但是有效的保证了服务稳定；

调优
--

### 单机限制

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

对发布端做适当流量控制，断开连接现象不再出现，但每秒消息数仍然不稳定

### 模式对性能的影响

分析三种模式 `direct` `fanout` `topic`

不同的模式对于新建交换机、新建队列、绑定等操作性能影响不大，

但是**在 direct 模式下明显消息发布的性能比其他模式强很多，并且消息发送到相同队列比发送到不同队列性能稍好**

### 持久化对消息性能的影响

在消息持久化模式下：

```
发布：13888msg/s 
订阅：15384msg/s
```

在消息非持久化模式下：

```
发布：18867msg/s 
订阅：26315msg/s
```

问题分析 / 解决方案
-----------

问题分析：

可以看到 RabbitMQ 的内存 占用占用已经使用了`7.8G` 允许的值为 `.6G左右`

因为 `vm_memory_high_watermark` 值设置的是`0.4` 也就是物理内存的`40%` ；服务器为`16G * 40% = 6.4G`

一般在产生的原因是长期的生产者发送速率大于消费者消费速率导致. 触发了 RabbitMQ 的流控；

解决方案：

1.  增加消费者端的消费能力, 或者增加消费者 (根本解决)
2.  控制消息产生者端的发送速率 (不太现实)
3.  增加 mq 的内存 (治标不治本)

### 参数调优

`vm_memory_high_watermark`：用于配置内存阈值，建议小于 0.5，因为 Erlang GC 在最坏情况下会消耗一倍的内存。

`vm_memory_high_watermark_paging_ratio`：用于配置 paging 阈值，该值为 1 时，直接触发内存满阈值，block 生产者。

`IO_THREAD_POOL_SIZE`：CPU 大于或等于 16 核时，将 Erlang 异步线程池数目设为 100 左右，提高文件 IO 性能。

`hipe_compile`：开启 Erlang HiPE 编译选项（相当于 Erlang 的 jit 技术），能够提高性能 20%-50%。在 Erlang R17 后 HiPE 已经相当稳定，RabbitMQ 官方也建议开启此选项。

`queue_index_embed_msgs_below`：RabbitMQ 3.5 版本引入了将小消息直接存入队列索引（queue_index）的优化，消息持久化直接在 amqqueue 进程中处理，不再通过 msg_store 进程。由于消息在 5 个内部队列中是有序的，所以不再需要额外的位置索引 (msg_store_index)。该优化提高了系统性能 10% 左右。

`queue_index_max_journal_entries`：journal 文件是 queue_index 为避免过多磁盘寻址添加的一层缓冲（内存文件）。对于生产消费正常的情况，消息生产和消费的记录在 journal 文件中一致，则不用再保存；对于无消费者情况，该文件增加了一次多余的 IO 操作。

### 最佳线程

*   生产者使用多线程发送数据到 queue **三到五个线程性能发送最佳**，超过它也不能提高生产的发送速率。
*   消费者的数据处理，**使用二线程接收性能是最佳的**，如数据处理程序处理比较复杂的逻辑，建议多开启几个线程进行数据接收。
*   在发送接收队列中, 因为发送的速率总比接收的速率要快，因此考虑在接收端配置比发送端更多的线程，个人认为:`接收者线程 = 发送者线程 X 1.5`

### 数据恢复

*   RabbitMq 在做数据恢复时，遇到过一次数据恢复不了后就没有办法复现。数据恢复的时间会随着数据量的大小成直线增长。

### 集群

没测

### 用 iptables 适当的限制连接