作家
登錄

TCP窗口被填滿問題的排查實踐

作者: 來源: 2022-02-09 15:32:09 閱讀 我要評論

   問題背景:

  某日17:12左右,收到實施人員投訴,有部分設備不能正常升級、收不到控制臺下發的指令等問題,同事查看control工程(后面簡稱control)那邊的日志,發現control沒有收到設備上報的影子信息,所以沒有下發指令。control工程直接對接設備,根據設備上報的信息對設備下發一些指令及配置信息,包括升級、上報日志等,IoT平臺上線之前control依賴心跳上報來獲取設備的當前信息,IoT平臺上線之后依賴設備影子信息來獲取設備的當前信息,control會訂閱設備的影子信息,但影子信息是由影子服務(簡稱IoT)轉發過去的,它不直接對接設備影子上報,具體流轉細節,

  請看這下面兩個圖:

  應用程序(control)獲取設備狀態

  

 

  應用程序(control)下發設備指令

  

 

  得知control收不到影子消息以后,我立馬去rabbitmq的控制臺查看是否有消息,

  確定兩個事:

  1.設備是否上報了消息

  2.rabbitmq是否正常

  下面圖1、圖2是當時截取的rabbitmq控制臺的兩個圖,從圖1可以很清楚的確定設備是有消息上報的,但是有很多消息是unacked(說明已經投遞給了消費者,只是消費者沒有ack而已,理論上等待一段時間就能正常)的,具體是哪個隊列堆積unacked的消息請看圖2,“spacebridgeiot-shadow”正是我們用來接收設備上報的影子信息的隊列,消息都被堆積到隊列了所以沒有轉發到control也是合理的,觀察了一段時間發現unacked的數量變成了0,但是total的總數確沒有太大變化,給人的感覺像是unacked的消息重新回到了消息隊列里等待投遞,果然過了幾分鐘以后又發現有大量unacked的消息,過了幾分鐘以后這部分unacked的消息重新回到隊列里,control那邊依然沒有收到消息,這時查看IoT那邊的日志發現竟然沒有影子消息進來,在rabbitmq的控制臺查看“spacebridgeiot-shadow”這個隊列下居然沒有消費者了,如圖3所示。

  這時查看rabbitmq的日志確實有錯誤信息,如圖4所示,rabbitmq主動關閉了連接。

  圖1:rabbitmq概覽圖

  

 

  圖2:rabbitmq隊列統計圖

  

 

  圖3:spacebridgeiot-shadow 概覽

  

 

  圖4:rabbitmq報錯信息

  

 

  臨時解決方案:

  由于當時已經有大量投訴過來了,所以采用了比較暴力的解決辦法“將堆積的消息刪除”,刪除以后果然正常了(備注:線上問題必須盡快解決,沒有時間允許我們去分析日志然后有條不紊的解決,必須快)。

  通過線下環境復現問題:

  1.往10.200.41.166環境的rabbitmq的隊列“mirrorTestQueue”堆積大量消息(起碼萬級)

  2.停掉mirrorTestQueue的消費者,待堆積完成以后重新啟動

  3.堆積完成,重新啟動消費者

  

 

  和我們設想的一樣,幾秒內有幾千條消息推給了消費者,持續幾分鐘以后rabbitmq主動關閉了和消費者之間的連接,這時從控制臺看不到隊列的消費者。

  由于我們的消費者設置了自動恢復,所以過一陣又會自動連上,但很快又會被斷連,和我們線上遇到的問題基本一樣,究竟是什么導致了這個問題呢?說實話當時沒有什么思路,網上找了一圈也沒找到什么特別滿意的答案(當時沒有抓到問題的本質,搜的關鍵詞太泛了),后來我們猜測可能是TCP層面出了什么問題,所以決定抓包試試能不能找到什么端倪。

  果然,幸運的事情發生了,話不多說,直接上圖。

  

 

  

 

  13:06:25.643428之前rabbitmq還一直在給消費者推消息,直到13:06:25.643428這個時間點,開始出現消費者tcp窗口被打滿的情況,大概持續了30秒左右,rabbitmq主動斷開了連接(發了一個rst包),之后消費者重連,然后窗口又繼續被打滿,又持續30秒左右繼續被斷連。

  

 

  

 

  感覺還挺有規律,每次持續30s,感覺是可配置的一個參數,大概總結一下就是“tcp full window導致了服務端主動rst連接,而且還有規律”

  這次換了一下搜索的關鍵詞找到了答案,rabbitmq有一個參數叫tcp_listen_options.send_timeout 是來控制寫超時的一個參數,當寫超時了以后就會觸發tcp的RST(https://github.com/rabbitmq/rabbitmq-java-client/issues/341),修改一下試試效果如何:

  1. 將寫超時時間改成10s

  tcp_listen_options.send_timeout = 10000

  2.抓包看看是否起作用

  

 

  

 

  可以看到從窗口滿到關閉連接持續10s左右,說明這個參數是起作用的。

  現象復盤:

  由于rabbitmq的消費端沒有設置prefetch所以rabbitmq一次性給消費端投遞了過多的消息,從而導致消費端的 tcp 窗口被占滿,進而觸發了rabbitmq 的tcp_listen_options.send_timeout,這個寫超時達到一個閾值后會觸發rabbitmq斷開消費者的tcp 連接。

  終極解決方案:

  之前刪除消息只是迫不得已的方案,雖然解決了問題但太暴力,我們需要找到一個優雅的方案來應對,既然是推給消費者的消息太多造成了tcp窗口被打滿,那我們就應該在接收速率上下點功夫,在連接rabbitmq的時候告訴它別給我發太多就行。

  后面這段話摘自 https://www.jb51.net/article/236407.htm

  rabbitmq有一個屬性叫prefetchprefetch是指單一消費者最多能消費的unacked messages數目。

  如何理解呢?mq為每一個 consumer設置一個緩沖區,大小就是prefetch。每次收到一條消息,MQ會把消息推送到緩存區中,然后再推送給客戶端。當收到一個ack消息時(consumer 發出baseack指令),mq會從緩沖區中空出一個位置,然后加入新的消息。但是這時候如果緩沖區是滿的,MQ將進入堵塞狀態。更具體點描述,假設prefetch值設為10,共有兩個consumer。也就是說每個consumer每次會從queue中預抓取 10 條消息到本地緩存著等待消費。同時該channel的unacked數變為20。而Rabbit投遞的順序是,先為consumer1投遞滿10個message,再往consumer2投遞10個message。如果這時有新message需要投遞,先判斷channel的unacked數是否等于20,如果是則不會將消息投遞到consumer中,message繼續呆在queue中。之后其中consumer對一條消息進行ack,unacked此時等于19,Rabbit就判斷哪個consumer的unacked少于10,就投遞到哪個consumer中。

  具體到代碼里就是

  

 

  如何評估這個值呢,rabbitmq官方有個文章說的很好,就不細說了,我們的系統中目前設置的是20。

  https://www.rabbitmq.com/blog/2012/05/11/some-queuing-theory-throughput-latency-and-bandwidth/

  結束語:

  對于關鍵組件的使用一定要熟悉其api,理解各個參數的含義和語法,當出現問題時不要局限于組件層面排查,必要的時候需要深入到底層,比如網絡,操作系統等。

  以上就是TCP窗口被填滿問題的排查實踐的詳細內容,更多關于TCP窗口填滿問題排查的資料請關注腳本之家其它相關文章!


  推薦閱讀

  架構思維之緩存雪崩的災難復盤

  1 真實案例  云辦公系統用戶實時信息查詢功能優化發布之后,系統發生宕機事件(系統掛起,頁面無法加載)! 1.1 背景  我們IM原有的一個功能,當鼠標移動到用戶頭像的時候,會顯示出用戶的基本信息。信息比>>>詳細閱讀


本文標題:TCP窗口被填滿問題的排查實踐

地址:http://www.jychbg.com/kaifa/yejie/41188.html

關鍵詞: 探索發現

樂購科技部分新聞及文章轉載自互聯網,供讀者交流和學習,若有涉及作者版權等問題請及時與我們聯系,以便更正、刪除或按規定辦理。感謝所有提供資訊的網站,歡迎各類媒體與樂購科技進行文章共享合作。

網友點評
自媒體專欄

評論

熱度

精彩導讀
欄目ID=71的表不存在(操作類型=0)
免费观看人成视频在线播放