RabbitMq 最全的性能調優(yōu)筆記

Tony 發(fā)布于2019-08-19 11:09 / 1585人閱讀

摘要：性能調優(yōu)筆記避免雷區(qū)要避免流控機制觸發(fā)服務端默認配置是當內存使用達到，磁盤空閑空間小于，即啟動內存報警，磁盤報警報警后服務端觸發(fā)流控機制。最佳線程生產者使用多線程發(fā)送數(shù)據(jù)到三到五個線程性能發(fā)送最佳，超過它也不能提高生產的發(fā)送速率。

RabbitMq 性能調優(yōu)筆記

[TOC]

避免雷區(qū) 要避免流控機制觸發(fā)

服務端默認配置是當內存使用達到40%，磁盤空閑空間小于50M，即啟動內存報警，磁盤報警；報警后服務端觸發(fā)流控（flowcontrol）機制。

一般地，當發(fā)布端發(fā)送消息速度快于訂閱端消費消息的速度時，隊列中堆積了大量的消息，導致報警，就會觸發(fā)流控機制。

觸發(fā)流控機制后，RabbitMQ服務端接收發(fā)布來的消息會變慢，使得進入隊列的消息減少；

與此同時RabbitMQ服務端的消息推送也會受到極大的影響，測試發(fā)現(xiàn)，服務端推送消息的頻率會大幅下降，等待下一次推送的時間，有時等1分鐘，有時5分鐘，甚至30分鐘。

一旦觸發(fā)流控，將導致RabbitMQ服務端性能惡化，推送消息也會變得非常緩慢；

因此要做好數(shù)據(jù)設計，使得發(fā)送速率和接收速率保持平衡，而不至于引起服務器堆積大量消息，進而引發(fā)流控。通過增加服務器集群節(jié)點，增加消費者，來避免流控發(fā)生，治標不治本，而且成本高。

服務器單節(jié)點，單網卡全雙工情況下，測試發(fā)現(xiàn)發(fā)布速度過快，壓滿發(fā)布PC機帶寬，對于服務器來說，下行（接收）帶寬也會壓滿，可是上行（轉發(fā)遞送）帶寬卻出現(xiàn)了明顯的下降，似乎有一個爭搶。這可能是導致觸發(fā)流控的原因。

從底層取數(shù)據(jù)一定要非常及時

訂閱端每隔500MS調用一次amqp_consume_message接口函數(shù)從socket上獲取數(shù)據(jù)，正常情況下，服務器每次會推送幾百條消息，而且推送的頻率會比較高；

導致訂閱端的本機socket緩沖區(qū)會很快存滿，導致很多消息無法進行緩存，而被丟掉；

發(fā)布消息條數(shù)	調用amqp_comsume_message間隔(MS)	實際接收條數(shù)
630	500	269
695	470	269
513	460	269
503	450	503

消息大小不要超過4MB

客戶端與RabbitMQ服務端的最大幀是128K，但消息大小卻可支持數(shù)MB，這是可能是因為底層做了拆包組包的，目前我還未查看底層代碼。

用線程來模擬50個發(fā)布者和50個訂閱者；

消息包大小由1K到10MB，當包大小達到4.5MB時，服務器的性能出現(xiàn)明顯的異常，傳輸率尤其是每秒訂閱消息的數(shù)量，出現(xiàn)波動，不穩(wěn)定；同時有一部分訂閱者的TCP連接出現(xiàn)斷開的現(xiàn)象?？赡苁强蛻舳说讓踊蛘逺abbitMQ服務端在進行拆包，組包的時候，出現(xiàn)了明顯的壓力，而導致異常的發(fā)生。

超過4MB的消息，最好先進行分包

consume時預取參數(shù)的大小對consume性能影響很大

具體可參見官方博客

磁盤也可能形成瓶頸

磁盤也可能形成瓶頸，如果單臺機器隊列很多，確認只在必要時才使用duration(持久化)，避免把磁盤跑滿；

隊列的消息大量累積后

隊列的消息大量累積后，發(fā)送和消費速度都會受到影響，導致服務進一步惡化，采用的方法是，額外的腳本監(jiān)控每個隊列的消息數(shù)，超過限額會執(zhí)行purge操作，簡單粗暴但是有效的保證了服務穩(wěn)定；

調優(yōu) 單機限制

由于用線程模擬大量發(fā)布者，且是服務器單節(jié)點，受客戶端主機網卡的限制，發(fā)布線程沒有速度控制，導致有大量數(shù)據(jù)發(fā)送，服務器帶寬下行速率也滿負荷，上行帶寬卻明顯低于下行速率，導致服務器內存有大量消息堆積，進而觸發(fā)RabbitMQ服務器paging操作，才出現(xiàn)了上述不穩(wěn)定和訂閱者斷開現(xiàn)象。

對發(fā)布端做適當流量控制，斷開連接現(xiàn)象不再出現(xiàn)，但每秒消息數(shù)仍然不穩(wěn)定

模式對性能的影響

分析三種模式 direct fanout topic

不同的模式對于新建交換機、新建隊列、綁定等操作性能影響不大，

但是在direct模式下明顯消息發(fā)布的性能比其他模式強很多，并且消息發(fā)送到相同隊列比發(fā)送到不同隊列性能稍好

持久化對消息性能的影響

在消息持久化模式下：

發(fā)布：13888msg/s 
訂閱：15384msg/s

在消息非持久化模式下：

發(fā)布：18867msg/s 
訂閱：26315msg/s

問題分析/解決方案

問題分析：

可以看到RabbitMQ的內存占用占用已經使用了7.8G 允許的值為 .6G左右

因為 vm_memory_high_watermark 值設置的是0.4 也就是物理內存的40% ；服務器為16G * 40% = 6.4G

一般在產生的原因是長期的生產者發(fā)送速率大于消費者消費速率導致. 觸發(fā)了RabbitMQ 的流控；

解決方案：

增加消費者端的消費能力,或者增加消費者(根本解決)

控制消息產生者端的發(fā)送速率(不太現(xiàn)實)

增加mq的內存(治標不治本)

參數(shù)調優(yōu)

vm_memory_high_watermark：用于配置內存閾值，建議小于0.5，因為Erlang GC在最壞情況下會消耗一倍的內存。

vm_memory_high_watermark_paging_ratio：用于配置paging閾值，該值為1時，直接觸發(fā)內存滿閾值，block生產者。

IO_THREAD_POOL_SIZE：CPU大于或等于16核時，將Erlang異步線程池數(shù)目設為100左右，提高文件IO性能。

hipe_compile：開啟Erlang HiPE編譯選項（相當于Erlang的jit技術），能夠提高性能20%-50%。在Erlang R17后HiPE已經相當穩(wěn)定，RabbitMQ官方也建議開啟此選項。

queue_index_embed_msgs_below：RabbitMQ 3.5版本引入了將小消息直接存入隊列索引（queue_index）的優(yōu)化，消息持久化直接在amqqueue進程中處理，不再通過msg_store進程。由于消息在5個內部隊列中是有序的，所以不再需要額外的位置索引(msg_store_index)。該優(yōu)化提高了系統(tǒng)性能10%左右。

queue_index_max_journal_entries：journal文件是queue_index為避免過多磁盤尋址添加的一層緩沖（內存文件）。對于生產消費正常的情況，消息生產和消費的記錄在journal文件中一致，則不用再保存；對于無消費者情況，該文件增加了一次多余的IO操作。

最佳線程

生產者使用多線程發(fā)送數(shù)據(jù)到queue三到五個線程性能發(fā)送最佳，超過它也不能提高生產的發(fā)送速率。

消費者的數(shù)據(jù)處理，使用二線程接收性能是最佳的，如數(shù)據(jù)處理程序處理比較復雜的邏輯，建議多開啟幾個線程進行數(shù)據(jù)接收。

在發(fā)送接收隊列中,因為發(fā)送的速率總比接收的速率要快，因此考慮在接收端配置比發(fā)送端更多的線程，個人認為:接收者線程 = 發(fā)送者線程 X 1.5

數(shù)據(jù)恢復

RabbitMq在做數(shù)據(jù)恢復時，遇到過一次數(shù)據(jù)恢復不了后就沒有辦法復現(xiàn)。數(shù)據(jù)恢復的時間會隨著數(shù)據(jù)量的大小成直線增長。

集群

沒測

用iptables適當?shù)南拗七B接

云服務器 GPU云服務器性能調優(yōu) webrtc性能調優(yōu) tomcat性能調優(yōu) PostgreSQL性能調優(yōu)

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉載請注明本文地址：http://systransis.cn/yun/77087.html

復盤2021最全2340頁面試題：jvm+spring+redis+MQ+微服務

摘要：題庫第版包括集合多線程并發(fā)編程設計模式全家桶大數(shù)據(jù)阿里巴巴等大廠面試題等等技術棧話不多說直接上圖部分內容預覽大數(shù)據(jù)頁深度調優(yōu)，演講互聯(lián)網面試答案深度調優(yōu)大數(shù)據(jù)文檔關注我私信回復即可領取。題庫第2版包括 Java 集合、JVM、多線程、并發(fā)編程、設計模式、Spring全家桶、Java、My...

princekin 2021-09-29 09:35 評論0 收藏0
Java學習路線總結，搬磚工逆襲Java架構師（全網最強）

摘要：哪吒社區(qū)技能樹打卡打卡貼函數(shù)式接口簡介領域優(yōu)質創(chuàng)作者哪吒公眾號作者架構師奮斗者掃描主頁左側二維碼，加入群聊，一起學習一起進步歡迎點贊收藏留言前情提要無意間聽到領導們的談話，現(xiàn)在公司的現(xiàn)狀是碼農太多，但能獨立帶隊的人太少，簡而言之，不缺干 ? 哪吒社區(qū)Java技能樹打卡?【打卡貼 day2...

Scorpion 2021-11-18 10:02 評論0 收藏0
史上最全阿里 Java 面試題總結

摘要：以下為大家整理了阿里巴巴史上最全的面試題，涉及大量面試知識點和相關試題。的內存結構，和比例。多線程多線程的幾種實現(xiàn)方式，什么是線程安全。點擊這里有一套答案版的多線程試題。線上系統(tǒng)突然變得異常緩慢，你如何查找問題。以下為大家整理了阿里巴巴史上最全的 Java 面試題，涉及大量 Java 面試知識點和相關試題。 JAVA基礎 JAVA中的幾種基本數(shù)據(jù)類型是什么，各自占用多少字節(jié)。 S...

winterdawn 2019-08-19 11:02 評論0 收藏0
寫這么多系列博客，怪不得找不到女朋友

摘要：前提好幾周沒更新博客了，對不斷支持我博客的童鞋們說聲抱歉了。熟悉我的人都知道我寫博客的時間比較早，而且堅持的時間也比較久，一直到現(xiàn)在也是一直保持著更新狀態(tài)。 showImg(https://segmentfault.com/img/remote/1460000014076586?w=1920&h=1080); 前提好幾周沒更新博客了，對不斷支持我博客的童鞋們說聲：抱歉了！。自己這段時...

JerryWangSAP 2019-08-16 11:11 評論0 收藏0
優(yōu)秀文章收藏（慢慢消化）持續(xù)更新~

摘要：整理收藏一些優(yōu)秀的文章及大佬博客留著慢慢學習原文協(xié)作規(guī)范中文技術文檔協(xié)作規(guī)范阮一峰編程風格凹凸實驗室前端代碼規(guī)范風格指南這一次，徹底弄懂執(zhí)行機制一次弄懂徹底解決此類面試問題瀏覽器與的事件循環(huán)有何區(qū)別筆試題事件循環(huán)機制異步編程理解的異步 better-learning 整理收藏一些優(yōu)秀的文章及大佬博客留著慢慢學習原文:https://www.ahwgs.cn/youxiuwenzhan...

JeOam 2019-08-23 18:24 評論0 收藏0