【linux雜談】跟隨大牛進行一次服務器間通信問題的排查

發現應用記錄日誌內，出現網絡訪問延遲較大的狀況。

此類問題較爲常見，特別是以前參與輔助一個朋友項目運維的過程當中，常常由於網絡訪問延遲較大，朋友認爲是遭到了ddos攻擊或者是cc攻擊。網絡訪問延遲較大經常會給頂層業務帶來損失，甚至嚴重影響用戶體驗。

遇到這類問題，首先根據OSI七層模型，從上到下，儘量脫離更加高層的協議帶來的影響。通常說來，稍微有經驗的人都會採用ping的方式，經過探尋icmp是否工做正常，來直接從網絡層面進行定位。

經過測試電腦ping業務服務器，發現以下詭異的回包狀況：

能夠看到，這張圖片內展現的上下部分，延遲極低，屬於正常。可是中間部分出現了延遲極高的現象。不但如此，紅框內的延遲變化狀況，呈現詭異的逐步下降態勢。

若是是業務長期故障，延遲應該是高、數值穩定的。若是是偶發現象，延遲應該是忽然增大，先後無變化趨勢的。這種有規律的從833ms逐步下降到10ms上下，讓人不由思考，這個裏面是否是隱藏着更大的祕密？

假設，在出現故障的時候，服務器的表現是一直再等待處理，故障過去，服務器忽然統一按照順序開始處理，那麼形成的結果就是——先發包的回包延遲極大，後續發包延遲逐漸下降。是否是十分吻合上述的狀況？

若是這個假設成立，那麼事情就變得更加有趣了起來~

咱們先要明白，當網卡捕獲到icmp包的時候，須要向CPU提起中斷申請，CPU發生中斷，才能處理回包請求。那麼，若是CPU在一段時間內，因爲特殊緣由，拒絕中斷，那麼不就會形成上文所說的那種假設狀況嗎？

事情逐漸明朗了起來。可是即使這種拒絕中斷的狀況發生了，那麼如何才能找到這個拒絕中斷的緣由呢？還真沒有這麼簡單。不簡單的緣由很簡單，硬件中斷自己優先級要高於通常進程和軟中斷，在其被禁用以後天然普通軟件層面的追蹤方法也不起做用了。

因此目前尚無很好的方法在不影響業務的狀況下較輕量級地得到禁用中斷時的內核堆棧。

走到這個地步的時候，那麼咱們就須要從外露出來的其餘指標看看，還有沒有什麼解決問題的突破口~

果真系統的內存佔用較高，可是並無發現明顯的異常程序佔用，就感受憑空少了一塊。

這時候咱們能夠考慮一下slab的問題。

cat /proc/meminfo |grep -i slab

經過這個命令，咱們能夠了解總共的slab佔用。若是發現顯示出來的數據確實很大，那麼咱們有必要調用slabtop進一步查看slab相關的佔用高的內容。

咱們能夠看到這個dentry佔用極高。dentry是內存中表示目錄與文件的對象，用於連接inode。確定是出現了什麼大量打開文件或目錄的狀況。

那麼，又回到一開始的問題，咱們發現了ping的問題，感受可能和系統禁用中斷有關，如今又發現內存佔用高，找到了dentry大量佔用資源的事實。這兩者之間有必然聯繫嗎？

答案是有的。

託大神指導，咱們看到了2.6內核的源碼。下面這張圖片內展現的源碼，實現了一個計算slab總量的功能。

咱們能夠看到內核是經過遍歷鏈表的方式，進行統計計數。而在進入鏈表以前，調用了spin_lock_irq函數。咱們再繼續跟進，看看這個函數的相關實現。

至此，真相大白。咱們能夠確認在統計slab信息的時候，系統的行爲是首先禁用中斷，而後遍歷鏈表統計slab，最後再次啓用中斷。那麼整個禁用中斷的時間將取決於鏈表中對象的個數，若是其對象數量驚人，極可能就會致使禁用中斷時間過長。

固然，驗證這個關聯是否存在，也是能夠簡單實現的。首先，咱們在測試機上長ping業務服務器。而後，在業務服務器上執行如下代碼：

cat /proc/slabinfo

系統獲取slabinfo一樣會調用s_show函數，從而觸發禁止中斷。最終，固然發現再次出現了本文開頭同樣的幽靈ping延遲變化。至此，表面緣由基本已經找到。

從緩解問題的角度來考慮，此時因爲dentry項自己是做爲系統緩存而存在，因此利用如下指令釋放緩存，dentry項會被清空，且不影響硬盤上的實際文件。

echo 2 > /proc/sys/vm/drop_caches && sync

至此，問題已經從表面上緩解。

可是，深層次的來講，還要繼續探究爲何會出現這麼多的異常文件和目錄打開？這一塊須要繼續從業務層面進行排查。

不過從下降網絡延遲的角度考慮，在目前情境下，設定當slab中dentry比例再次達到某一水平的時候，進行釋放緩存，能夠長久自動化維持正常水平，不影響排查工做的進行。