【调优案例】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指令查看


欢迎关注个人公众号
在这里插入图片描述

  • 7
    点赞
  • 28
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 2
    评论
RabbitMQ是一个开源的企业级消息队列系统,它具有高度可扩展性和可靠性。在进行RabbitMQ性能压测时,我们可以采取以下几个方面的方法来评估其性能: 1. 高并发测试:通过发送大量的消息并进行高并发的消费操作来测试RabbitMQ的并发性能。可以模拟多个客户端同时发送消息,然后观察RabbitMQ在高并发情况下的处理能力和消息吞吐量。 2. 延迟测试:通过发送一条消息并进行消费的时间来评估RabbitMQ的消息延迟性能。可以通过记录消息发送的时间和消费的时间间隔来计算延迟时间,并观察消息延迟在不同负载下的表现。 3. 持久化消息测试:测试RabbitMQ在持久化消息的情况下的性能表现。可以将消息设置为持久化,然后发送大量的消息并进行消费操作,观察消息的持久化能力和系统的稳定性。 4. 高可靠性测试:测试RabbitMQ在节点故障或网络断开的情况下的可靠性表现。可以模拟节点宕机或网络中断的情况,观察RabbitMQ在故障恢复后是否能够正确处理消息并保持系统的可用性。 在进行性能压测时,需要注意以下几个方面: 1. 测试环境的准备:需要构建一个具有一定规模的测试环境,包括多个生产者、消费者和消息队列节点,以模拟真实的生产环境。 2. 压测工具的选择:可以使用一些专业的压测工具,如Apache JMeter等,来模拟高并发的消息发送和消费操作。 3. 参数的调优:可以尝试调整RabbitMQ的参数,如连接池大小、线程池大小等,以获得更好的性能表现。 4. 结果的分析:在进行性能压测后,需要对测试结果进行分析和比较,以评估系统的性能和稳定性,并找出可能存在的性能瓶颈和优化点。 通过以上的测试和分析,可以对RabbitMQ性能进行全面的评估,并根据实际需求来合理调整配置和优化系统,以提升其性能和可靠性。
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

sysu_lluozh

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值