【调优案例】rabbitMQ压测_rabbitmq 性能压测结果

线上环境出现问题，由于某数据上报接口的大量请求，导致rabbitmq的消息队列中Ready消息超过300W条，rabbitmq挂掉

信息确认

• 确认线上数据库配置
  线上数据库几主几从，多少个分库
  数据库配置文件须和线上保持一致（bin_log）
  数据库容量应和线上环境一致
• 确认服务器是否有第三方系统依赖
• 最大多少个线程生产消息和最大多少个线程消费消息
• 确认线上并发数据
  线上最大TPS
  线上最大线程数

业务逻辑

• 客户端HTTP上报数据
• adapt接收数据，解析并封装数据
• adapt做为生产者给rabbitMQ发送消息
• rabbitMQ将消息放入消息队列，出列时处理数据
• friday做为消费者消费消息，将消息存在redis中

测试方案

locust进行压测，分布式控制拓扑图

测试点

1. 只生产不消费，生产者的速率
2. 只消费不生产，消费者的速率
3. Ready数据量400W，随着生产者速率增大消费者的速率
4. Ready数据量0，随着生产者速率增大消费者的速率

测试数据

看一下其中的异常数据，以下数据为Ready数据量0，随着生产者速率增大消费者的速率的数据

很明显：

1. 在incoming速率小于3200时，incoming和deliver / get速率在一个稳定的生产和消费
2. 在incoming速率大于3200时，随着incoming速率的增大，deliver / get速率急剧减小

报告中需要原因分析和解决方案

配置流控或者增加消费节点

rabbitmq.config 修改配置

在线上出现问题的时候第一时间是解决线上故障，然后再考虑长远的解决方案

Memory 水位线

触发流控机制
线上做不同的流控配置后压测，然后再验证下同样配置下增加消费端会不会提高峰值

指令 rabbitmqctl set_vm_memory_high_watermark 0.7
或者修改配置文件

Memory红色触发流控，或者磁盘标红

长时间压数据，10min，看是否标红

83M - 833M - 2.5G - 3.3G - 5.4G - 971M in和get速率降为0一小会后，Memory降到980MB MQ崩溃自动重启，Ready里面的数据还有

怀疑那个界面不准

rabbitmqctl purge_queue + 队列名称

杀掉其他进程后你把水位调到0.7

另外一个可以尝试的就是去掉持久化，这样不需要存磁盘，磁盘IO就少了，应该就差不多了，如果还是出现income大于get，那就只能增加消费线程了

系统是多少bit

客户端去持久化要把exchange和queue和message的都去除掉。最好你自己弄个jmeter插件来搞，这样你爱怎么改就怎么改。如果有时间还有消费端的ack也可以试试去掉。反正压测调优就这样了，除了应用程序本身的调优，剩下的就是各种配置的尝试了，最终找到一个比较合理的方案就是目的

确认MQ的上行下行带宽，再压一把，压测时候的MQ服务器的网络带宽的上行和下行速率是多少，如果上行（接受消息的方向）带宽爆了，再看下MQ服务器的paging
对比手法匹配的时候paging的收大于发时候的paging
MQ流控导致大量消息积压

装一个dstat，直接看paging，yum install -y dstat ，然后dstat -tamp 看paging的数据

发消息的工具是否持久化？现在的机制是HTTP请求

vmstat 1 100 看si和so

在压测的时候，同时查看dstat和iostat的数据
iostat 1 100

再压测一把，然后看数据，这次使用iostat -dxc 2
发现物理内存不够，为啥物理内存用28G

得了解哪个进程用了那么多的内存，目前MQ不是线上环境

iostat发现还没压测的时候，磁盘IO就45%，磁盘看%util数据

查看哪个磁盘占用IO，pidstat -d 1

看到几个进程在消耗IO，看看分别是什么进程

ps -ef | grep 1381
ps -ef | grep 13691

不是在docker而不是物理机

把消耗磁盘的进程杀掉
kill -9

一般使用物理机压测，压测时候一定要保持环境干净，所有的网络和io使用都干净，特别是数据库，一个多余的链接都没有

进一步压测，发现内存一步步没了，然后MQ挂掉

发消息客户端应该是开启了ack和持久化，试试关掉这两个再压一次，那拐点值应该会上升不少，现在看着是CPU都浪费在等磁盘IO，应该是消费端来不及消费，然后rabbitMQ要把消息持久化到磁盘，这个过程浪费了io和cpu，所以试试把持久化还有ack关掉

现在使用的locust，用HTTP发送请求产生数据，模拟消息到adapter，然后由adapter去发消息

封装jmeter插件

怎么查看系统的内存信息
cat /proc/meminfo

水位默认0.4,32*0.4 = 12.8

top查看内存信息

现在free内存加上buffer内存加起来5G多，buffer的内存不能百分百的释放，撑爆也就3、4G可用内存

查看21544的进程是什么java应用，可以的话就停掉

vm_memory_high_watermark，设置内存低水位线，若低于该水位线，则开启流控机制，默认值是0.4，即内存总量的40%
设置的12G水位线，现在才剩1G free，可以将水位线改成3G试试

干掉21544的进程，top指令查看

---

欢迎关注个人公众号