前言

日常 Bug 排查系列都是一些簡單 Bug 的排查。筆者將在這里介紹一些排查 Bug 的簡單技巧，同時順便積累素材。

Bug 現場

最近碰到一個問題，一臺機器上的連接數在達到一定連接數 (大概 4.5W) 連接數之后會突然急速下降到幾百。在應用上的表現就是大量的連接報錯，系統失去響應，如下圖所示: 

思路

思路 1: 第一步肯定是懷疑代碼寫錯了，筆者看了下，使用的是成熟的框架，不是自己操作的連接，那么代碼的問題應該較小。
思路 2：那么筆者就開始懷疑是內核的限制，例如文件描述符到頂了之類，但這又有一個矛盾點。一旦是內核對連接數量限制的話，應該是連接數到達一定程度就漲不上去，而不是連接數跳水式下降。
思路 2.1: 進一步，筆者就開始想，很有可能是某個間接資源的限制導致到達這個瓶頸后，所有的連接獲取這個資源獲取不到而導致全部報錯。再結合 TCP 連接消耗的資源無非就是 CPU / 內存 / 帶寬。

監控信息

有了上面的思路，我們就可以觀察相關監控信息了。 CPU 監控：CPU 消耗很高達到了將近 70%，但獲取不到 CPU 一般只會導致響應變慢，和問題現象不匹配。 帶寬監控：帶寬利用率達到了 50%，這個帶寬利用率算不上高。 內存監控：確實使用了大量的內存，RSS 達到了 26G，但是比起 128G 的內存而言，這點消耗量顯然不可能成為瓶頸。 好了，看了這三個數據之后，就發現系統的資源消耗還稱不上達到瓶頸。但是，筆者從一開始就懷疑內存的使用可能觸發了某個特殊的瓶頸。因為只有內存資源申請不到之后，TCP 連接才有可能直接報錯進而 Drop 連接。

TCP 監控信息

當傳統的監控已經不足以分析我們問題的時候，筆者就直接掏出針對 TCP 問題最有效的統計命令了，祭出法寶:

# 這條命令詳細的輸出了tcp連接的各種統計參數，很多問題都可以通過其輸出獲得線索
netstat -s

筆者在這條命令的輸出中詳細的觀察 TCP 以及 TCP 內存相關的輸出項，定睛一看，就發現一個很不尋常的地方:

...
TcpExt:
 TCP ran low on memoery 19 times
 ......

這個輸出就和筆者對于內存限制的猜想完全對應起來了。TCP 內存不夠了，導致讀取或者寫入數據的時候申請內存失敗進而將 TCP 連接本身給 Drop 了。

修改內核參數

因為筆者之前詳細的閱讀過 Linux TCP 的源代碼以及其所有的可調整的內核參數。所以對 TCP 的內存限制有映像。有了 GPT 之后，只需要知道一個大致的方向就好了，直接問 GPT 就給出了答案，就是 tcp_mem 這個參數。

cat /proc/sys/net/ipv4/tcp_mem
1570347 2097152 3144050

這三個值分別代表了 tcp 對于內存在不同閾值下的不同使用策略，單位是頁，也就是 4KB。具體解釋可以直接去問 GPT，在此就不贅述了。核心就是 TCP 消耗的內存總量在大于第三個值也就是 3144050 (12G，占 128G 內存的 9.35%) 的時候 TCP 就開始由于內存申請不到而 Drop 連接。而對應的應用由于每個請求高達好幾 M 確實會讓每個 TCP 連接消耗大量的內存。
在內存消耗過程中一旦超限，那么 TCP 連接就會被內核強制 Drop，這也解釋了為什么基本所有連接在很短的時間內就跳水式 Drop，因為他們都在不停申請內存，而達到臨界閾值后全部都報錯，進而整個系統的所有連接都關閉導致系統失去響應。如下圖所示: 

圖片

知道是這個問題就很簡單了，直接將 tcp_mem 調大即可：

cat /proc/sys/net/ipv4/tcp_mem
3570347 6097152 9144050

調整后系統保持穩定

在經過響應的內核調整之后，系統的連接數超過了 5W 之后依舊保持穩定。這時候我們觀察相關的 TCP 消耗內存頁的輸出:

cat /proc/net/sockstat
TCP: inuse xxx orphan xxx tw xxx alloc xxxx mem 4322151

從這個輸出我們可以看到系統平穩運行后，其常態使用的內存頁數量 mem 為 4322151 已經遠大于之前的 3144050，這也從側面驗證了筆者的判斷。

對應的內核棧

在此記錄下對應的 Linux 內核棧

tcp_v4_do_rcv
 |->tcp_rcv_established
  |->tcp_data_queue
   |->tcp_data_queue
    |->tcp_try_rmem_schedule
     |->sk_rmem_schedule
      |->sk_rmem_schedule
       |->__sk_mem_raise_allocated
         |-> /* Over hard limit. */
          if (allocated > sk_prot_mem_limits(sk, 2))
          goto suppress_allocation;
   |->goto drop:
    tcp_drop(sk,skb)

可以看到當 allocated 大于相關的內存 limit 之后 Linux Kernel 會將此 TCP 連接直接 Drop。

總結

筆者在了解清楚 Bug 現場之后，大概花了 20 分鐘就定位到了是 TCP 內存瓶頸的問題，然后借助 GPT 非常快速的找到了相關解決方案。不得不說 GPT 能夠大幅加速我們搜索的過程，筆者個人感覺可以在很大程度上替代搜索引擎。但喂給 GPT 的 Prompt 還是需要通過 Bug 現場以及一定的經驗來構造，它代替不了你的思考，但能大幅加速信息的檢索。