先說明下RocketMQ版本, 4.6.0的老版本了。
線下環境客戶端啟動會頻繁報錯響應超時,導致consumer實例化失敗,無法啟動應用。
圖片
確認線下環境RocketMQ集群流量、生產消費數量無異常。
集群gc次數不多,但是耗時高。(原本監控看板異常數據缺失,所以少了前面一段)
圖片
master節點cpu使用率、load極高。
圖片
升配,4c8g升級8c32g,擴大jvm內存。
系統指標略有下降,但是客戶端異常沒有明顯改善。
只能進一步排查根因,還得上arthas。
thread -n 3
查看cpu高的線程在做什么。
發現兩個異常線程。
1)一個線程在執行AdminBrokerProcessor.queryTopicConsumerByWho()。
圖片
這個是查詢Topic的conusmerGroup信息。
比較奇怪的是,這個請求很頻繁,后來發現是控制臺應用dashboard有個定時任務,30s查詢一次。
這個請求的耗時主要是在數組的遍歷處理上,說明內存中的數據非常大。
圖片
而這個源碼中的offsetTable,就是RocketMQ中保存consumerGroup位點信息的對象。它的key是topic@group拼接的。
圖片
先臨時處理,把dashboard應用關閉了,減少請求。但是效果并不明顯。
2)另一個線程在執行定時任務ConsumerOffsetManager.persist()。
(線程調用信息忘記截圖了)
這個是RocketMQ集群持久化consumerGroup的offset信息的定時任務。
圖片
會將整個內存對象轉化為jsonString寫入磁盤文件中。
這個內存對象就是前面提到的offsetTable,就是RocketMQ中保存consumerGroup位點信息的對象。
這里消耗資源多,還是說明我們的內存對象非常大。
因為是線下環境,可靠性要求不高。所以先臨時處理,把定時任務默認配置5s改成50s,減少持久化次數。
效果顯著,機器cpu、負載都明顯改善。
好了,現在問題的矛頭都指向了這個offsetTable,那它到底有多大,為什么這么大?
大對象的定位,一般來說需要dump看看,不過這個對象有點特殊,剛剛也提到了它會被持久化到文件中,所以直接看文件大小和內容就行了。
持久化文件的配置路徑,可以看下啟動的conf.properties
storePathRootDir=/usr/local/rocketmq/store1storePathCommitLog=/usr/local/rocketmq/store1/commitlogstorePathConsumerQueue=/usr/local/rocketmq/store1/consumequeuestorePathIndex=/usr/local/rocketmq/store1/index
在/usr/local/rocketmq/store1目錄下找到config文件夾的consummerOffset.json文件,44M,amazing~
對一個幾十M的對象頻繁序列化和持久化,加上內網磁盤比較差,難怪負載如此高。
圖片
(這里截圖是當時應急時備份的文件,新的文件目前是414K)
為什么這個內存對象這么大呢?
查看了下文件內容,是RocketMQ中保存consumerGroup位點信息的對象,它的key是topic@group拼接的。
我們發現大量奇怪的consumerGroup name,跟一個topic聯合產生了幾千個key。
查看了下內部封裝的客戶端代碼,找到了罪魁禍首。
圖片
線下環境會根據小環境(比如自己起的測試、單測環境、CI測試環境等)拼接一個獨立的consumerGroup name。
在線下,每次CI的測試環境名字會變化,所以導致consumerGroup name數量急劇膨脹。
問題找到了,直接的解決方式是刪除文件中無用的consumerGroup name,重啟broker進行加載。
由于是線下環境,不需要擔心位點丟失的問題,同時當客戶端請求時會自動創建新的位點信息,所以可以考慮直接刪除。
圖片
先停止broker進程(否則會自動落盤內存數據,創建新的文件),然后重命名相關文件(用于備份回滾),重新啟動broker進程,讀取空文件加載空對象。
重啟后,各個客戶端在請求集群時,會自動創建訂閱關系和消費位點記錄,負載略有升高,然后就恢復到較低的負載水位了。
24h的監控顯示,優化效果顯著,整個機器負載降低,請求讀寫耗時也顯著降低。
圖片
注意:保存訂閱關系的subscriptionGroup.json也存在同樣consumerGroup過多導致膨脹的問題,同樣的原因和優化方式。默認訂閱關系也是會自動創建的。這里就不展開贅述了。
如果類似的問題出在線上怎么辦?
事后來看,類似問題是能夠提前避免的,主要考慮兩個措施:
本文鏈接:http://www.www897cc.com/showinfo-26-67353-0.html消費者太多!RocketMQ又炸了!
聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯系,我們將在第一時間刪除處理。郵件:2376512515@qq.com
上一篇: 太失望了!前端社區對 React 的抱怨越來越多...
下一篇: 每個開發人員都應該閱讀的九篇非凡文獻