摘要:性能調優筆記避免雷區要避免流控機制觸發服務端默認配置是當內存使用達到,磁盤空閑空間小于,即啟動內存報警,磁盤報警報警后服務端觸發流控機制。最佳線程生產者使用多線程發送數據到三到五個線程性能發送最佳,超過它也不能提高生產的發送速率。
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適當的限制連接文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/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...
閱讀 3049·2021-11-18 10:02
閱讀 3315·2021-11-02 14:48
閱讀 3384·2019-08-30 13:52
閱讀 527·2019-08-29 17:10
閱讀 2070·2019-08-29 12:53
閱讀 1392·2019-08-29 12:53
閱讀 1018·2019-08-29 12:25
閱讀 2155·2019-08-29 12:17