前言

G行某平臺類應用系統提供高并發、低延遲的服務請求，該系統的的響應時間在1毫秒左右，目前最大TPS在2.5萬左右，為保證該系統的快速響應，系統設置的超時時間為30毫秒。在一次巡檢中發現，該系統的幾臺服務器超時交易筆數在逐漸增加，為避免系統運行風險，協調網絡、操作系統等專家一同分析，在分析過程中補充學習了大量Linux操作系統內核的知識，現將分析過程及其中用到的知識點記錄下來，以便為解決類似的問題提供一個通用的解決思路。

一、應用系統超時現象

外部系統將請求發送到前端服務，前端服務進行業務邏輯后重新組裝報文，將請求發送到后端服務。交易處理超時體現在前端服務對后臺服務的請求上，但是根據網絡設備的鏡像網絡包分析，后端服務的處置時間沒有異常，前端發送給后端的請求，后端都可以快速的處理。因此問題還是出現在前端服務上。

圖1 系統邏輯架構

由于該系統的交易量大、響應時間低，所以對處理過程的日志記錄較少，根據前端服務的應用日志無法定位根本原因。針對前端服務到后臺服務的請求，選一段超時交易較多的時間段的網絡鏡像包進行分析。發現超時交易集中在兩個固定的時間點，分別為：11:29:4.200，超時9筆，平均TCPack_rtt為5毫秒；11:29:54.100，超時2筆，平均TCPack_rtt為6毫秒，在這兩個時間段超時交易的rtt都大于30毫秒，沒有超時的交易也有部分ack的rtt相對較長。其他正常交易時間段的ack_rtt在0.06毫秒左右。

圖2 網絡鏡像包異常現象

根據這個現象初步懷疑在網絡收發包上出現了擁堵問題，操作系統網絡協議棧對收到的網絡包沒有及時處理。具體處理過程為前端發送請求到后端服務，后端服務立即進行了響應并返回響應包，由于協議棧沒有及時處理響應包，導致相應的ack包沒有及時返回，同時導致前端服務沒有及時收到后端服務的返回，從而出現超時的現象。

為驗證懷疑的方向，將一臺服務器進行物理重啟，重啟后超時現象消失；同時將另外一臺服務器只重啟應用系統，超時現象沒有出現緩解。因此可以確定交易的超時現象是由于操作系統的原因導致，和應用系統的處理性能無關。

二、問題排查

由于懷疑和操作系統的協議棧處理有關，為便于問題排查，同時避免對生產的穩定運行造成影響，我們使用perf和hping3進行異常的復現和問題分析。perf是Linux的一款性能分析工具，能夠進行系統內核函數級和指令級的熱點查找，可以用來分析程序中熱點函數的CPU占用率，從而定位性能瓶頸。Hping3是一個開源網絡工具，通過rawSocket直接組裝icmp、udp、tcp報文，并記錄對方服務器的ack響應時間。

圖3 問題排查方案

分析方案是找同子網的另外一臺服務器部署hping3工具，向異常服務器不停的發送tcp報文，并記錄ack返回出現延遲的時間點。在異常的服務器上部署perf工具，跟蹤操作系統的內核調用，以便發現異常點。通過hping3每1毫秒發送一個網絡包，記錄其收到ack包的時間，可以發現在1650140557這個時間點出現大量rtt時間較長的情況，分析perf工具采集的內核調用數據，可以發現在相同的時間點存在大量ss進程發起的請求，當時正在執行的系統調用函數為read，根據調用棧proc_reg_read可以定位為程序正在讀取/proc目錄下的文件內容。

圖4 內核系統異常調用棧

由于生產服務器上部署了各種代理和大量的監控腳本，因此懷疑是由這些代理、監控腳本發起的ss命令調用，在系統中查找使用ss命令的腳本，可以發現調用ss的命令行為圖5所示。

圖5 觸發異常的shell調用

通過strace跟蹤ss 調用過程，如圖6所示。

圖6 trace跟蹤ss調用過程

關注read處理較慢的系統調用，可以發現read處理時間超過10ms的地方共有5處，最長的處理時間在189ms；根據文件句柄號3，可以確認正在讀取的文件為”/proc/slabinfo”。

圖7 ss命令系統調用的異常

至此可以確認網絡包接收卡頓，是由于監控周期性調用ss命令導致。ss命令會讀取/proc/slabinfo，而在讀取的時候有部分read函數的系統調用處理較慢，從而影響了網絡接收包的處理。

為進一步驗證上述結論，我們將異常服務器上使用ss命令的監控腳本停止，并啟動前端服務將其加入生產隊列，經過長時間觀察，未再發現超時現象。然后手工在服務器上連續執行幾次cat /proc/slabinfo，可以發現超時現象再次出現。

三、深入分析原因

1.第一個疑問：為什么讀取/proc/slabinfo會導致網絡包接收卡頓？

網絡協議棧接收tcp報文并自動返回ack，是操作系統在中斷中處理的，優先級別較高，而用戶讀取/proc/slabinfo是一般的系統調用，為什么會影響內核的中斷處理呢？首先需要了解一下Linux操作系統代碼執行的幾個上下文場景。

硬件中斷上下文：優先級別最高，只要有硬件中斷發生就會被立即執行，這里包括時鐘中斷、網卡中斷；

軟件中斷上下文：在硬件中斷執行完成或系統調用完成時執行，這個是操作系統內核核心代碼執行的主要環境，包括進程調度，網絡協議棧處理等等；

內核進程上下文：運行在內核態，但是受進程調度管理，按進程調度分配的時間片執行，超過執行的時間片就有可能被別的進程搶占而暫停執行；

用戶進程上下文：這個是大部分應用程序執行的環境，受進程調度管理，按進程調度分配的時間片執行，超過執行的時間片會強制進行進程切換。

那他們的執行優先級是不是就是：硬件中斷> 軟件中斷> 內核進程>  用戶進程。實際并不完全是這樣，由于硬件中斷、軟件中斷、內核進程都運行在內核態，運行在相同的地址空間，所有的數據都是共享的，如果硬件中斷強制中斷軟件中斷的執行，軟件中斷強制中斷內核進程的執行，那么有可能會導致內核數據的混亂或者導致各種死鎖，為了保護臨界數據的安全和完整性，軟件中斷可以關硬件中斷，內核進程可以關閉硬件中斷和軟件中斷。

在執行cat/proc/slabinfo時，首先程序運行在用戶進程上下文，然后執行系統調用read被切換到內核進程上下文，由于slabinfo中存儲的是內核的內存分配信息，在讀取內存分配信息時為了保證數據的一致性，在內核進程上下文中關閉了硬件中斷和軟件中斷。由于進程調度也是通過硬件中斷中的時鐘中斷觸發的，所以如果長時間的關閉硬件中斷、軟件中斷，進程調度也不會被執行。如果read執行時間較長，關閉中斷的時間就會比較長，該進程就會長時間占用CPU不釋放，阻止了內核協議棧對網絡收包的處理。

查看Linux內核代碼/linux-3.0.101/mm/slab.c中的s_show函數，可看到如下關閉中斷的代碼

圖8 讀取slabinfo時關閉中斷的內核代碼

2.第二個疑問：服務器具有40CPU，為什么一個ss命令就會阻止網絡包的處理呢，理論上應還有另外39個CPU來處理?

這個涉及RPS（ReceivePacket Steering）和RFS（ReceiveFlowSteering）技術，其主要功能就將高速網卡產生的大量網絡包分配到多核CPU分別進行處理，但是這個分配是預分配，根據socket四元組（源IP、源端口、目的IP、目的端口）分配到不同的CPU進行處理。ss命令在哪個CPU上執行，那么分配到這個CPU上的網絡包處理就會出現卡頓。因此在生產環境的表現上也是只有部分網絡包出現了卡頓，而不是所有的網絡包都會產生卡頓。

3.第三個疑問：讀取/proc/slabinfo為什么會慢？

Slab算法是以字節為單位管理內存，是內核的小內存管理算法。特點是基于對象進行管理。slab分配算法采用cache存儲內核對象，把相同類型的對象歸為一類，每當要申請這樣一個對象，slab分配器就從一個slab列表中分配一個這樣大小的單元出去，而當要釋放時，將其重新保存在該列表中，而不是直接返回給伙伴系統，從而避免這些內碎片。slab分配器并不丟棄已分配的對象，而是釋放并把它們保存在內存中。當以后又要請求新的對象時，就可以從內存直接獲取而不用重復初始化。

通過cat /proc/slabinfo可以查看slab分配的內存情況，其中包含的信息主要為統計信息，包括每種對象內存的總個數、已分配的個數、每頁內存的對象個數、占用的內存頁數等等。這些統計信息是怎么來的呢？是內核中現成的統計數據嗎？通過查看代碼可以發現，是一個個累加匯總來的，如果內存對象的個數較多，那將是一個非常耗時的大循環。其內核代碼如下：

通過cat /proc/slabinfo | sort -n-k3的輸出，查看一下哪些內存對象的個數較多。

圖9 slab內存對象數量

如圖9所示占用比較高的幾項是dentry、buffer_head、proc_inode_cache。dentry 是文件目錄對inode映射的緩存；Buffer_head 是硬盤的塊緩存；proc_inode_cache 是/proc目錄下inode節點信息的緩存。dentry、proc_inode_cache分別達到了797萬和388萬，這個數據量非常大，導致在輸出/proc/slabinfo時耗時較長。

4.第四個疑問：為什么重啟服務器后網絡包卡頓現象就消失，其后為什么會變慢呢？

重啟后卡頓現象消失這個問題現在很容易回答，那就是由于重啟后slab中的緩存信息全部釋放了，對象個數較少，再統計slabinfo時處理較快，不會影響網絡包的接收了。重啟運行一段時間后會再出現卡頓現象，是由于slab中緩存的信息又變多了，那是誰導致slab緩存了大量信息呢？

slab中個數較多的內存對象是dentry和proc_inode_cache，在查看/proc目錄下的文件時，操作系統會自動將目錄信息和inode信息緩存到這兩個對象。因此是有程序周期性的讀取/proc目錄下的文件導致這兩個內存對象緩存個數增多的。再次跟蹤一下ss命令可以發現ss命會掃描/proc下所有進程打開的文件句柄，包括socket鏈接。我們這臺服務器經常保持數萬的鏈接數，這些鏈接的存活時間最短只有幾秒鐘，最長也就幾個小時。因此執行一次ss-lntp命令會緩存數萬的proc_inode_cache和dentry，如果周期性的執行這個命令，打開的socket句柄又不停的發生變化，就會導致slab緩存的數量不斷增長。

四、問題解決

通過上面的分析可以確認導致網絡包卡頓的原因是：周期性的調用ss-lntp命令，同時這臺服務器上的網絡鏈接不斷發生變化，使得slab中緩存了大量的內存對象，并且ss會讀取/proc/slabinfo中的匯總信息，而slabinfo中的匯總信息是每次通過效率不高的一個個累加的方式獲得，且累加時關閉了操作系統的中斷處理，導致接收到的網絡包無法及時處理。

因此可采取的解決方案：

（1）執行echo "2" > /proc/sys/vm/drop_caches ，強制操作系統回收inode和dentry中的緩存信息。這個命令執行期間會造成系統卡頓，卡頓時間為幾秒到幾分鐘，關鍵業務運行期間需慎用；

（2）周期性重啟服務器，釋放slab中的緩存信息；

（3）停止周期性調用ss -lntp；

（4）對于ss命令，可以去掉 -p 參數，去掉這個參數后，ss將不再掃描/proc目錄下的進程信息，不會導致slab中內存對象個數的增長。另外也可以升級到高版本的ss命令，在高版本的ss命令中已不再讀取 /proc/slabinfo,因為這里面已沒有可以獲取的有效信息。下面是github中的commit信息。

圖10 GitHub中commit信息

總結

針對這個問題的分析持續了大約一、兩個月的時間，期間也曾一度陷入迷惑而毫無進展，有初步分析思路后補充了操作系統內核的各種知識，主要包括進程調度、調度優先級、中斷處理、網絡協議棧處理、虛擬文件系統等等，最終可以將整個問題的來龍去脈解釋清楚。

參考資料：

《如何調試Kubernetes集群中的網絡延遲問題？》Theo Julienne 分布式實驗室

《網卡多隊列：RPS、RFS、RSS、FlowDirector（DPDK支持）》rtoax CSDN

https://rtoax.blog.csdn.net/article/details/108987658

https://github.com/shemminger/iproute2/commit/10f687736b8dd538fb5e2bdacf6bef2c690ee99d