摘要：性能调优笔记避免雷区要避免流控机制触发服务端默认配置是当内存使用达到，磁盘空闲空间小于，即启动内存报警，磁盘报警报警后服务端触发流控机制。最佳线程生产者使用多线程发送数据到三到五个线程性能发送最佳，超过它也不能提高生产的发送速率。
RabbitMq 性能调优笔记
[TOC]
避免雷区 要避免流控机制触发服务端默认配置是当内存使用达到40%，磁盘空闲空间小于50M，即启动内存报警，磁盘报警；报警后服务端触发流控（flowcontrol）机制。
一般地，当发布端发送消息速度快于订阅端消费消息的速度时，队列中堆积了大量的消息，导致报警，就会触发流控机制。
触发流控机制后，RabbitMQ服务端接收发布来的消息会变慢，使得进入队列的消息减少；
与此同时RabbitMQ服务端的消息推送也会受到极大的影响，测试发现，服务端推送消息的频率会大幅下降，等待下一次推送的时间，有时等1分钟，有时5分钟，甚至30分钟。
一旦触发流控，将导致RabbitMQ服务端性能恶化，推送消息也会变得非常缓慢；
因此要做好数据设计，使得发送速率和接收速率保持平衡，而不至于引起服务器堆积大量消息，进而引发流控。通过增加服务器集群节点，增加消费者，来避免流控发生，治标不治本，而且成本高。
服务器单节点，单网卡全双工情况下，测试发现发布速度过快，压满发布PC机带宽，对于服务器来说，下行（接收）带宽也会压满，可是上行（转发递送）带宽却出现了明显的下降，似乎有一个争抢。这可能是导致触发流控的原因。
从底层取数据一定要非常及时订阅端每隔500MS调用一次amqp_consume_message接口函数从socket上获取数据，正常情况下，服务器每次会推送几百条消息，而且推送的频率会比较高；
导致订阅端的本机socket缓冲区会很快存满，导致很多消息无法进行缓存，而被丢掉；
| 发布消息条数 | 调用amqp_comsume_message间隔(MS) | 实际接收条数 |
|---|---|---|
| 630 | 500 | 269 |
| 695 | 470 | 269 |
| 513 | 460 | 269 |
| 503 | 450 | 503 |
客户端与RabbitMQ服务端的最大帧是128K，但消息大小却可支持数MB，这是可能是因为底层做了拆包组包的，目前我还未查看底层代码。
用线程来模拟50个发布者和50个订阅者；
消息包大小由1K到10MB，当包大小达到4.5MB时，服务器的性能出现明显的异常，传输率尤其是每秒订阅消息的数量，出现波动，不稳定；同时有一部分订阅者的TCP连接出现断开的现象。可能是客户端底层或者RabbitMQ服务端在进行拆包，组包的时候，出现了明显的压力，而导致异常的发生。
超过4MB的消息，最好先进行分包
consume时预取参数的大小对consume性能影响很大具体可参见官方博客
磁盘也可能形成瓶颈磁盘也可能形成瓶颈，如果单台机器队列很多，确认只在必要时才使用duration(持久化)，避免把磁盘跑满；
队列的消息大量累积后队列的消息大量累积后，发送和消费速度都会受到影响，导致服务进一步恶化，采用的方法是，额外的脚本监控每个队列的消息数，超过限额会执行purge操作，简单粗暴但是有效的保证了服务稳定；
调优 单机限制由于用线程模拟大量发布者，且是服务器单节点，受客户端主机网卡的限制，发布线程没有速度控制，导致有大量数据发送，服务器带宽下行速率也满负荷，上行带宽却明显低于下行速率，导致服务器内存有大量消息堆积，进而触发RabbitMQ服务器paging操作，才出现了上述不稳定和订阅者断开现象。
对发布端做适当流量控制，断开连接现象不再出现，但每秒消息数仍然不稳定
模式对性能的影响分析三种模式 direct fanout topic
不同的模式对于新建交换机、新建队列、绑定等操作性能影响不大，
但是在direct模式下明显消息发布的性能比其他模式强很多，并且消息发送到相同队列比发送到不同队列性能稍好
持久化对消息性能的影响在消息持久化模式下：
发布：13888msg/s 订阅：15384msg/s
在消息非持久化模式下：
发布：18867msg/s 订阅：26315msg/s问题分析/解决方案
问题分析：
可以看到RabbitMQ的内存 占用占用已经使用了7.8G 允许的值为 .6G左右
因为 vm_memory_high_watermark 值设置的是0.4 也就是物理内存的40% ；服务器为16G * 40% = 6.4G
一般在产生的原因是长期的生产者发送速率大于消费者消费速率导致. 触发了RabbitMQ 的流控；
解决方案：
增加消费者端的消费能力,或者增加消费者(根本解决)
控制消息产生者端的发送速率(不太现实)
增加mq的内存(治标不治本)
参数调优vm_memory_high_watermark：用于配置内存阈值，建议小于0.5，因为Erlang GC在最坏情况下会消耗一倍的内存。
vm_memory_high_watermark_paging_ratio：用于配置paging阈值，该值为1时，直接触发内存满阈值，block生产者。
IO_THREAD_POOL_SIZE：CPU大于或等于16核时，将Erlang异步线程池数目设为100左右，提高文件IO性能。
hipe_compile：开启Erlang HiPE编译选项（相当于Erlang的jit技术），能够提高性能20%-50%。在Erlang R17后HiPE已经相当稳定，RabbitMQ官方也建议开启此选项。
queue_index_embed_msgs_below：RabbitMQ 3.5版本引入了将小消息直接存入队列索引（queue_index）的优化，消息持久化直接在amqqueue进程中处理，不再通过msg_store进程。由于消息在5个内部队列中是有序的，所以不再需要额外的位置索引(msg_store_index)。该优化提高了系统性能10%左右。
queue_index_max_journal_entries：journal文件是queue_index为避免过多磁盘寻址添加的一层缓冲（内存文件）。对于生产消费正常的情况，消息生产和消费的记录在journal文件中一致，则不用再保存；对于无消费者情况，该文件增加了一次多余的IO操作。
最佳线程生产者使用多线程发送数据到queue三到五个线程性能发送最佳，超过它也不能提高生产的发送速率。
消费者的数据处理，使用二线程接收性能是最佳的，如数据处理程序处理比较复杂的逻辑，建议多开启几个线程进行数据接收。
在发送接收队列中,因为发送的速率总比接收的速率要快，因此考虑在接收端配置比发送端更多的线程，个人认为:接收者线程 = 发送者线程 X 1.5
数据恢复RabbitMq在做数据恢复时，遇到过一次数据恢复不了后就没有办法复现。数据恢复的时间会随着数据量的大小成直线增长。
集群没测
用iptables适当的限制连接文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/77087.html
摘要：题库第版包括集合多线程并发编程设计模式全家桶大数据阿里巴巴等大厂面试题等等技术栈话不多说直接上图部分内容预览大数据页深度调优，演讲互联网面试答案深度调优大数据文档关注我私信回复即可领取。 题库第2版 包括 Java 集合、JVM、多线程、并发编程、设计模式、Spring全家桶、Java、My...
摘要：哪吒社区技能树打卡打卡贴函数式接口简介领域优质创作者哪吒公众号作者架构师奋斗者扫描主页左侧二维码，加入群聊，一起学习一起进步欢迎点赞收藏留言前情提要无意间听到领导们的谈话，现在公司的现状是码农太多，但能独立带队的人太少，简而言之，不缺干 ? 哪吒社区Java技能树打卡 【打卡贴 day2...
摘要：以下为大家整理了阿里巴巴史上最全的面试题，涉及大量面试知识点和相关试题。的内存结构，和比例。多线程多线程的几种实现方式，什么是线程安全。点击这里有一套答案版的多线程试题。线上系统突然变得异常缓慢，你如何查找问题。 以下为大家整理了阿里巴巴史上最全的 Java 面试题，涉及大量 Java 面试知识点和相关试题。 JAVA基础 JAVA中的几种基本数据类型是什么，各自占用多少字节。 S...
摘要：前提好几周没更新博客了，对不断支持我博客的童鞋们说声抱歉了。熟悉我的人都知道我写博客的时间比较早，而且坚持的时间也比较久，一直到现在也是一直保持着更新状态。 showImg(https://segmentfault.com/img/remote/1460000014076586?w=1920&h=1080); 前提 好几周没更新博客了，对不断支持我博客的童鞋们说声：抱歉了！。自己这段时...
摘要：整理收藏一些优秀的文章及大佬博客留着慢慢学习原文协作规范中文技术文档协作规范阮一峰编程风格凹凸实验室前端代码规范风格指南这一次，彻底弄懂执行机制一次弄懂彻底解决此类面试问题浏览器与的事件循环有何区别笔试题事件循环机制异步编程理解的异步 better-learning 整理收藏一些优秀的文章及大佬博客留着慢慢学习 原文:https://www.ahwgs.cn/youxiuwenzhan...
阅读 3048·2021-11-18 10:02
阅读 3314·2021-11-02 14:48
阅读 3383·2019-08-30 13:52
阅读 526·2019-08-29 17:10
阅读 2069·2019-08-29 12:53
阅读 1392·2019-08-29 12:53
阅读 1017·2019-08-29 12:25
阅读 2154·2019-08-29 12:17
