linux平台下server營運問題分析與定位

邏輯server通常的處理能力在3k/s -
1w/s之間，因業務特點而不同。邏輯server一般是自主開發的，雖然在上線前大都經過功能和壓力測試，但放到現網環境上部署後還是難免會出現一些問
題，有些問題是在灰階發布時就可以發現，而有些問題則是一個漫長的暴露過程。下面先總結一下大致的問題分類和定位方法。

 

    1. 程式BUG如fd泄漏或記憶體流失

    業務上線前一定要做壓測，同時查看進程消耗的記憶體與fd數，結合業務特性分析fd使用量是否合理，同時觀察記憶體使用量是不是最終會趨於穩定的值，如果一直增加，就肯定有泄漏。

    fd泄漏確認方法是：ls /proc/pid/fd -al |
wc，可以看到單個進程使用的fd數，觀察是否一直在漲長，如果沒有最終達到一個穩定值，則可以確認存在泄漏。同時可以cat
/proc/net/sockstat觀察整體的fd使用數量是否一直在漲長，通常32位的機器，fd超過10W時系統會到達瓶頸。

    記憶體流失確認方法是：top 看進程使用的RES 和
SHR，觀察是否一直在漲長，如果沒有最終達到一個穩定值，則可以確認存在泄漏。同時可以看下mem的使用量是否一直在增加。記憶體流失最終的結果是使用到
的swap分區，一旦出現這種情況，cpu的wa欄位會出現遠大於0的情況，表明cpu阻塞在等待輸入輸出上。

 

    2. 業務自然增長

   
這一點依賴於對請求數的統計，通過對前後幾天的對比，不難確認是否是業務自然增長，單機請求量上升使系統出現瓶頸，這種問題通過擴容可以輕鬆解決，但最好
的辦法是對系統的容量和關鍵參數如cpu\mem\eth加上監控，能夠做到提前警示，這樣不至於在出問題的時候緊急擴容。

 

    3. 特性變更導致使用者行為異常

   
舉個例子，有一次我在升級server時，基於效能的考慮，少返回了一個已無效的欄位，灰階升級一台機器後，發現系統負載升高了3倍，當時的第一反應是有
bug，使到cpu的使用突增，但vmstat發現 升級前cpu使用率 usr 和 sys大致是 14  7，升級後為 42
21，大致同比增長了3倍，再看一下請求數，發現請求數也同比增長，可見，是某些原因達致使用者在重試。

   
因為上線前經過功能測試，所以正常使用者的功能應該沒有問題，對比這些的版本發更，發現有可能是少返回了一個欄位，使外掛使用者解析失敗而不停重試，因此重新
加上欄位後再次發布，問題解決。從那次之後，總結了一點，當返回給使用者側的資料出現欄位變更時，一定要灰階發布確認是否影響到外掛使用者，如果有影響的話可
以返回通過假資料解決。

 

    4. 系統參數配置不當

   
舉個例子，一段時間發現在訪問高峰時段，進程會出現申請fd失敗的情況，由於某些介面採用短串連，每次處理都需要申請fd、處理、釋放fd，後來查看了系
統參數，發現/proc/sys/net/ipv4/tcp_tw_recycle 和
/proc/sys/net/ipv4/tcp_tw_reuse都配的是0，0表示不開啟加快回收fd和複用time_wait狀態的fd，導致短串連
關閉後，fd大面積處在time_wait狀態，因些新的請求由於申請不到fd而失敗，通過調整系統參數後問題解決。

 

    5. 編碼問題導致系統處理能力較差

     其實這個範疇的不能算是運營問
題，但是處理能力較差的系統會很容易到達瓶頸。在編碼過程中，一定要注意避免無謂的開銷，特別是系統調用等。這裡我總結了幾條供大家參考：配置只解析一
次，然後常駐記憶體或共用記憶體；常用的工具類如上報、寫日誌等，使用static或單件模式，保證只初始化一個；盡量採用長串連，減少fd申請、建串連、釋
放帶來的開銷；通知等非關鍵可丟失的訊息使用udp，只發不收；不列印不必要的日誌，而且要迴圈寫，防止記錄檔過大時出錯；外部介面逾時盡量短，防止進
程因外部介面問題被掛住；單個進程的設定最大處理時間長度，保證系統最差情況時的處理能力；少用time、stat等系統調用。

    系統調用方面，可以通過strace -c統計系統調用次數和耗時，從而對商務邏輯最佳化。strace -c的使用方法，詳見我的另一篇文章。 

    這裡舉個例子，我有一次strace
-c了一個處理進程，發現stat函數的cpu使用率非常高，然後strace跟蹤了一下進程的系統調用發現，該進程用到了一個統計上報的類，類本身是用
static初始化的，但類的上報介面中，每次都會初始化一個對象，對採樣進行分析，並進行上報，這時會解析一次採樣設定檔同時再解析一次上報配置文
件，所以雖然類本身是static但是已經沒有意義了，對象還是每次都會初始化，後來改造了一下，把介面中的對象用指標代替，只在第一次介面調用時初始
化，再次調用時，判斷指標非NULL，則直接使用。最佳化後，發現系統的cpu使用下降了近20%，可見，減少無謂的系統調用對系統的處理能力是有很大提升
的。

 

    以上總結了常見的營運問題和定位方法，相信大家大致有一套自已定位問題的方法，這裡我談下我定位問題的基本流程，供大家參考：

    1. 查看日誌

    通過查看系統日誌，可以第一時間確定是不是商務邏輯或外部介面出了問題，並可以結合代碼進程核實。

 

    2. 是否fd>10W

    cat /proc/net/sockstat，觀察tcp_use欄位，如果持續增長而不趨於穩定說明fd泄漏或串連數過多，>10w時系統會出現異常。

 

    3. 負載分析

    首先用vmstat 1，觀察cpu 、swap和r欄位，大致可以分為以下幾種情況：

    cpu的wa欄位遠>0，並且swap的si欄位遠>0，說明已經用到了交換分區，這時通過top觀察進程的RES和SHR欄位，如果RES欄位很大，並且持續增長，可以確認是存在記憶體流失。

    cpu的usr和sys成比例比較高，r欄位值也比較高，而swap使用量為0，說明可能是請求量有變化，這時核對請求量資料，是否成比例增長，如果是成比例增長的話，可以確認是請求量增大的原因，這時要根據幾天的請求量資料確認是突增還是自然增長。