日常Bug排查-連接突然全部關(guān)閉

日常Bug排查系列將介紹一些排查Bug的簡單技巧，并積累相關(guān)素材。

最近遇到一個問題，一臺機器上的連接數(shù)在達(dá)到一定數(shù)量（大約4.5W）后，突然急速下降到幾百。這導(dǎo)致大量連接報錯，系統(tǒng)失去響應(yīng)。

筆者首先懷疑代碼問題，但經(jīng)過檢查后發(fā)現(xiàn)使用的是成熟的框架，代碼問題較小。接著懷疑是內(nèi)核的限制，例如文件描述符到頂了之類，但這又有一個矛盾點。一旦是內(nèi)核對連接數(shù)量限制的話，應(yīng)該是連接數(shù)到達(dá)一定程度就漲不上去，而不是連接數(shù)跳水式下降。

進(jìn)一步懷疑是某個間接資源的限制導(dǎo)致到達(dá)瓶頸后，所有的連接獲取這個資源獲取不到而導(dǎo)致全部報錯。結(jié)合TCP連接消耗的資源無非就是CPU/內(nèi)存/帶寬。

有了上述思路，我們觀察相關(guān)監(jiān)控信息。CPU消耗很高，帶寬利用率達(dá)到了50%，內(nèi)存使用了大量的內(nèi)存，但系統(tǒng)的資源消耗還稱不上達(dá)到瓶頸。

當(dāng)傳統(tǒng)的監(jiān)控已經(jīng)不足以分析問題時，筆者使用了針對TCP問題最有效的統(tǒng)計命令，即netstat -s。在這條命令的輸出中，發(fā)現(xiàn)了一個很不尋常的地方：TCP ran low on memory 19 times。這個輸出和筆者對于內(nèi)存限制的猜想完全對應(yīng)起來了。

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

在經(jīng)過響應(yīng)的內(nèi)核調(diào)整之后，系統(tǒng)的連接數(shù)超過了5W之后依舊保持穩(wěn)定。這時候我們觀察相關(guān)的TCP消耗內(nèi)存頁的輸出。

在此記錄下對應(yīng)的Linux內(nèi)核棧。可以看到當(dāng)allocated大于相關(guān)的內(nèi)存limit之后Linux Kernel會將此TCP連接直接Drop。

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

• 異色邊緣龍局北辰卡組詳解
• 《怪化貓》系列第二章《火鼠》近日公開諸多新情報
• steam特賣頁面出現(xiàn)神秘粉發(fā)女孩 引發(fā)網(wǎng)友熱烈討論
• 大雪節(jié)氣活動：桃源深處有人家雪盛冬藏
• 游俠晚報：《絕地潛兵2》口碑上升 Fami通一周評分