為什麽使能RPS/RFS, 或者RSS/網卡多隊列後,QPS反而下降?
http://laoar.github.io/blog/2017/05/07/rps/
TL;DR
-
RPS
即receive side steering,利用網卡的多隊列特性,將每個核分別跟網卡的一個首發隊列綁定,以達到網卡硬中斷和軟中斷均衡的負載在各個CPU上。
他要求網卡必須要支持多隊列特性。 -
RPS
receive packet steering
他把收到的packet依據一定的hash規則給hash到不同的CPU上去,以達到各個CPU負載均衡的目的。
他只是把軟中斷做負載均衡,不去改變硬中斷。因而對網卡沒有任何要求。 -
RFS
receive flow steering
RFS需要依賴於RPS,他跟RPS不同的是不再簡單的依據packet來做hash,而是根據flow的特性,即application在哪個核上來運行去做hash,從而使得有更好的數據局部性。
我們可以看到很多案例,使用這些特性後提醒了網絡包的處理能力,從而提升QPS,降低RT。
但是,我們知道,任何一個優化特性都不是普遍適用的,都有他特定的場景來應用。
很多人對此可能會有疑惑,那很多優化功能不是都已經作為默認配置了麽,如果不是普遍適用的,幹嘛還要作為默認配置呢?
其實很簡單,一個優化特性可以作為默認配置,依據我的理解,只需要滿足下面這些特征即可:
- 對某些場景可以顯著提升性能
- 對大部分場景無害
- 對某一部分場景可能會損傷性能
所以Linux的很多配置都是可以靈活配置供選擇的。
下面我們就來看下RPS這些特性在哪些場景下才能發揮作用。
問題描述
業務方在使用KVM虛擬機進行性能壓測時,發現某一個核的softirq占比特別高,如下所示:
1
2
3
4
5
6
7
|
|
一句話解釋:這個kvm虛擬機只有一個網卡,有網絡包到達這個網卡後,它會給某一個cpu(如果沒有設置親和性,這個可以認為是隨機的一個cpu,然後就會一直固定在這個cpu上)發中斷,通知該cpu來處理這個包,然後cpu就會觸發一個軟中斷把該包送到tcp/ip協議棧(對於tcp包而言)裏去處理,該包被放入某一個socket的receive buffer中(如果是一個數據包),軟中斷結束。
%soft就是指的CPU耗在軟中斷處理上的時間。
可以看到核1的%soft很高,其他的核的%soft基本為0.
所以就想著把核1的%soft給均攤下,是否可以提升QPS。
我們想到的方法是網卡多隊列,或者RPS/RFS。用這種手段來把網卡軟中斷給均攤到其他的核上去。
其實,看到前面mpstat的顯示,如果對網卡多隊列,RPS/RFS很熟悉,就會意識到他們在這裏不適用。
可惜理解的不深,交了這次學費。
使能網卡多隊列後,果然是QPS不但沒有提升,反而有下降。
下面就是這次調優交的學費。
為了使描述更清晰(其實是因為我做分析的這個kvm虛擬機上沒有網卡多隊列,但是不影響,導致性能下降的原因是一致的),我們只分析RPS來看下為什麽性能會下降。
RPS的原理概述
- 基於CentOS-7
在這之前,軟中斷只能在硬中斷所在CPU上處理,使用RPS後,網卡軟中斷就可以分發到其他的CPU上去做處理了。
使能RPS後為什麽會導致QPS下降?
如上圖所示,使能了RPS後,會增加一些額外的CPU開銷:
- 收到網卡中斷的CPU會向其他CPU發IPI中斷,這體現在CPU的%irq上
- 需要處理packet的cpu會收到NET_RX_SOFTIRQ軟中斷,這體現再CPU的%soft上。請註意,RPS並不會減少第一個CPU的軟中斷次數,但是會額外給其他的CPU增加軟中斷。他減少的是第一個CPU的軟中斷的執行時間,即,軟中斷裏不再需要那麽多的時間去走協議棧做包解析,把這個時間給均攤到其他的CPU上去了。
量化對比數據
硬中斷次數的變化
這可以通過/proc/interrupts來觀察
1
|
|
-
使能RPS之後:
-
使能RPS之前:
可以看到,是能RPS後,增加了很多的Function call interrups,即IPI。
而virtio0-input.0(虛擬網卡產生的中斷,類似於圖中NIC產生的中斷)仍然只發給CPU1.
也可以通過dstat來看整體次數的對比
- 使能RPS之後:
1
2
3
4
5
6
7
|
|
- 使能RPS之前:
1
2
3
4
5
6
7
8
|
|
軟中斷次數的變化
這可以通過/proc/softirq來觀察
1
|
|
-
使能RPS之前:
-
使能RPS之後:
可以看到,CPU1上的RX_NET數相差不大比較接近,但是CPU0/2/3上各自都增加了NET_RX.
各個CPU利用率的變化
這可以通過mpstat來觀察
1
|
|
- 使能RPS之後
1
2
3
4
5
6
|
|
- 使能RPS之前
1
2
3
4
5
6
|
|
可以看到,整體而言,CPU的%soft增大了很多,%usr下降了一些。
我們知道%usr是衡量用戶態程序性能的一個指標,%usr越高,意味著執行業務代碼的時間就越多。如果%usr下降,那就意味著執行業務代碼的時間變少了,這顯然對於業務性能是一個危險信號。
至於%usr裏面如何來提高業務代碼執行效率,是另外的問題了,不討論。
結論,RPS適用的場景
使能了RPS後,會增加CPU的%soft,如果業務場景本身就是CPU密集的,CPU的負載已經很高了,那麽RPS就會擠壓%usr,即擠壓業務代碼的執行時間,從而導致業務性能下降。
適用場景
RPS如果想要提升業務性能,前提是除了網卡中斷所在的CPU外,其他的CPU都需要有一定的空閑時間,這樣使能RPS才能帶來收益,否則就會帶來額外開銷導致性能下降。
在這個場景下,RPS搭配RFS會帶來更好的收益,不討論。
有沒有更優的解決方案?
答案肯定是有的。
It is a SECRET!
為什麽使能RPS/RFS, 或者RSS/網卡多隊列後,QPS反而下降?