日常Bug排查-連接突然全部關閉 前言 日常Bug排查系列都是一些簡單Bug的排查。筆者將在這里介紹一些排查Bug的簡單技巧，同時順便積累素材。 Bug現(xiàn)場 最近碰到一個問題，一臺機器上的連接數(shù)在達到一定連接數(shù)(大概4.5W)連接數(shù)之后會突然急速下降到幾百。在應用上的表現(xiàn)就是大量的連接報錯，系統(tǒng)失去
日常Bug排查系列將介紹一些排查Bug的簡單技巧，并積累相關素材。
最近遇到一個問題，一臺機器上的連接數(shù)在達到一定數(shù)量（大約4.5W）后，突然急速下降到幾百。這導致大量連接報錯，系統(tǒng)失去響應。
筆者首先懷疑代碼問題，但經(jīng)過檢查后發(fā)現(xiàn)使用的是成熟的框架，代碼問題較小。接著懷疑是內核的限制，例如文件描述符到頂了之類，但這又有一個矛盾點。一旦是內核對連接數(shù)量限制的話，應該是連接數(shù)到達一定程度就漲不上去，而不是連接數(shù)跳水式下降。
進一步懷疑是某個間接資源的限制導致到達瓶頸后，所有的連接獲取這個資源獲取不到而導致全部報錯。結合TCP連接消耗的資源無非就是CPU/內存/帶寬。
有了上述思路，我們觀察相關監(jiān)控信息。CPU消耗很高，帶寬利用率達到了50%，內存使用了大量的內存，但系統(tǒng)的資源消耗還稱不上達到瓶頸。
當傳統(tǒng)的監(jiān)控已經(jīng)不足以分析問題時，筆者使用了針對TCP問題最有效的統(tǒng)計命令，即netstat -s。在這條命令的輸出中，發(fā)現(xiàn)了一個很不尋常的地方：TCP ran low on memory 19 times。這個輸出和筆者對于內存限制的猜想完全對應起來了。
因為之前詳細閱讀過Linux TCP的源代碼以及其所有的可調整的內核參數(shù)，所以對TCP的內存限制有映像。有了GPT之后，只需要知道一個大致的方向就好了，直接問GPT就給出了答案，就是tcp_mem這個參數(shù)。
在經(jīng)過響應的內核調整之后，系統(tǒng)的連接數(shù)超過了5W之后依舊保持穩(wěn)定。這時候我們觀察相關的TCP消耗內存頁的輸出。
在此記錄下對應的Linux內核棧�？梢钥吹疆攁llocated大于相關的內存limit之后Linux Kernel會將此TCP連接直接Drop。
筆者在了解清楚Bug現(xiàn)場之后，大概花了20分鐘就定位到了是TCP內存瓶頸的問題，然后借助GPT非�？焖俚恼业搅讼嚓P解決方案。不得不說GPT能夠大幅加速我們搜索的過程，筆者個人感覺可以在很大程度上替代搜索引擎。但喂給GPT的Prompt還是需要通過Bug現(xiàn)場以及一定的經(jīng)驗來構造，它代替不了你的思考，但能大幅加速信息的檢索。
本站所有軟件，都由網(wǎng)友上傳，如有侵犯你的版權，請發(fā)郵件[email protected]
湘ICP備2022002427號-10 湘公網(wǎng)安備：43070202000427號© 2013~2025 haote.com 好特網(wǎng)
