【性能测试】rabbitMQ压测
线上环境出现问题，由于某数据上报接口的大量请求，导致rabbitmq的消息队列中Ready消息超过300W条，rabbitmq挂掉
信息确认
- 确认线上数据库配置
线上数据库几主几从，多少个分库
数据库配置文件须和线上保持一致（bin_log）
数据库容量应和线上环境一致 - 确认服务器是否有第三方系统依赖
- 最大多少个线程生产消息和最大多少个线程消费消息
- 确认线上并发数据
线上最大TPS
线上最大线程数
业务逻辑
- 客户端HTTP上报数据
- adapt接收数据，解析并封装数据
- adapt做为生产者给rabbitMQ发送消息
- rabbitMQ将消息放入消息队列，出列时处理数据
- friday做为消费者消费消息，将消息存在redis中
测试方案
locust进行压测，分布式控制拓扑图
测试点
- 只生产不消费，生产者的速率
- 只消费不生产，消费者的速率
- Ready数据量400W，随着生产者速率增大消费者的速率
- Ready数据量0，随着生产者速率增大消费者的速率
测试数据
看一下其中的异常数据，以下数据为Ready数据量0，随着生产者速率增大消费者的速率的数据
很明显：
- 在incoming速率小于3200时，incoming和deliver / get速率在一个稳定的生产和消费
- 在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指令查看
欢迎关注个人公众号
