当前位置:   article > 正文

RabbitMQ—性能测试_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速率急剧减小

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

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

rabbitmq.config 修改配置

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

Memory 水位线

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

指令 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也可以试试去掉。反正压测调优就这样了,除了应用程序本身的调优,剩下的就是各种配置的尝试了,最终找到一个比较合理的方案就是目的

3、确认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指令查看

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/繁依Fanyi0/article/detail/393661
推荐阅读
相关标签
  

闽ICP备14008679号