赞
踩
线上环境出现问题,由于某数据上报接口的大量请求,导致rabbitmq的消息队列中Ready消息超过300W条,rabbitmq挂掉
locust进行压测,分布式控制拓扑图
看一下其中的异常数据,以下数据为Ready数据量0,随着生产者速率增大消费者的速率的数据
很明显:
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指令查看
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。