騰訊成本優化黑科技：整機CPU利用率最高提高至90%

做者：騰訊TLinux團隊

導語：騰訊TLinux團隊提出了一套全新的混部方案，在不影響在線業務的前提下，對整機CPU利用率提高效果很是明顯，在有的業務場景下，整機CPU利用率甚至能提高至90%。

1、前言
騰訊運營着海量的服務器，且近年的增加有加速的趨勢，成本問題日益嚴峻。其中，CPU利用率不高一直是影響整機效率的短板。試想一下，若是能讓整機的CPU利用率翻一翻，是什麼概念？這至關於把一臺機器當兩臺使用，能爲公司節省鉅額的成本開銷。所以，各BG各業務都在想辦法提高整機CPU利用率。你們嘗試讓各類業務混部，試圖達到提升整機CPU利用率的目的。然而，方案的實際效果卻不盡如人意。現有的混部方案始終沒法作到離線業務不影響在線，這種影響直接致使多數業務沒有辦法混部。

基於現狀以及業務的需求，TLinux團隊提出了一套全新的混部方案，該方案已在公司不少業務中獲得了普遍的驗證，在不影響在線業務的前提下，對整機CPU利用率提高效果很是明顯，在有的業務場景下，整機CPU利用率甚至能提高至90%。

本文將圍繞如何提高整機CPU利用率這個問題來展開，重點關注如下三個問題：

現有混部方案如何作？問題是什麼？爲何如今CPU利用率仍是不高？
TLinux團隊的方案是如何作的？爲何要這麼作？
TLinux團隊的混部方案，真實業務使用效果如何？
2、現有方案
公司內部已有的混部方案總結來說主要有兩種：

Cpuset方案
Cgroup方案
1.cpuset方案
既然擔憂離線在線在相同的CPU上互相影響，那麼把在線&離線業務直接隔離開是最容易想到的方案，這就是cpuset方案，具體作法以下圖所示：

cpuset方案
在線業務限定在某些核上，離線業務限定在某些核上面。這種作法，在某些場景下，是有效果的，由於從物理上將離在線隔離開了，他們之間互不影響（超線程，cache互相影響這裏不展開細說）。可是這種方案實用性不強，好比在多線程的業務場景，須要利用多核優點，若是將在線限定到少數幾個核就會影響性能。而且，這種方案並無真正的達到混部的效果，在在線的那些核上，仍是沒有辦法混部離線業務。

2.cgroup方案
Cgroup方案，就是利用cgroup提供的share以及period/quota功能來實現。Share是經過給不一樣的cgruop配置權重來達到控制不一樣cgroup CPU佔用時間的目的。period/quota是能夠控制單位時間內某個cgroup佔用CPU的時間。你們想經過這兩種功能，來控制離線調度組的佔用CPU時間。這種方案在那種對時延不敏感的業務上，有必定效果。可是，不管是share仍是period/quota，都沒有辦法解決一個問題，就是在線沒法及時搶佔離線的問題。從而在延遲敏感的業務場景，使用group方案會致使在線受影響，業務沒法混部。

cgroup方案
同時，cgroup方案還有一些他自身方案帶來的問題，好比說period/quota控制須要遍歷整個cgroup樹影響性能問題，quota過小致使整機死鎖問題。

3.現有方案歸納
除了上述兩種方案，在業務層面的調度層，有的業務也作了一些工做，好比說根據機器以往的CPU使用狀況，在該機器CPU利用率的時候，從集羣中其餘機器上調度離線過來運行。這一樣也會有問題，好比業務突發流量如何即便處理不影響在線？在線雖然佔CPU低，可是延遲敏感，仍是沒法運行離線的問題。

總結起來，現有的混部方案在改善CPU利用率低下問題上，在某些場景有必定效果。可是現有方案對問題的改善有限，而且在不少對延遲敏感性的業務場景，使用現有方案是沒法混部的。由於，現有混部方案都沒法解決一個核心問題，就是如何作到讓離線不影響在線的問題。而致使離線業務影響在線業務的緣由就是，在線須要CPU的時候並不能及時搶佔離線。TLinux團隊的方案解決了這個問題，而且作了不少優化，目的是在離線不影響在線以後，讓離線可以見縫插針的利用空閒CPU，提高整機CPU利用率。

3、TLinux團隊的混部方案
1.方案框架
TLinux團隊混部方案在內核層面對離在線混部提供支持，從功能將主要包括，離線調度類支持，負載均衡優化，帶寬限制，用戶接口提供。咱們提供了離線專用調度類，專爲離線進程設計。而且對負載均衡作了深刻的優化，從而達到提高整機CPU利用率的目的。另外，爲了業務更加方便的使用該方案，咱們還爲業務提供了完善的離線進程設置控制接口。

TLinux團隊混部方案框架
方案中最重要的兩個問題是：

如何讓在線及時搶佔離線？
如何讓離線高效的利用空閒CPU？
以下圖所示，爲了解決在線搶佔離線不及時的問題，咱們專門爲離線設計了離線專用調度類，爲了讓離線更好的利用空閒CPU，咱們對負載均衡作了大量的優化，下面就一個一個來細說。

方案概覽圖
2.如何讓在線及時搶佔離線？
在說明這個問題解決以前，咱們先來分析一下，爲何現有的混部方案沒辦法作到及時搶佔。

搶佔邏輯，以下圖所致，在同調度類優先級的進程，互相搶佔的時候，須要知足兩個條件。第一個是搶佔進程的虛擬時間要小於被搶佔進程，第二是被搶佔進程已經運行的實際要大於最小運行時間。若是兩個條件不能同時知足，就會致使沒法搶佔。如今混部方案，在線離線都是cfs，這樣當在線須要CPU試圖搶佔離線的時候，兩個條件並不必定會知足，從而就致使在線搶佔不及時，這也是現有方案問題的關鍵。

搶佔邏輯
在當時制定方案，分析清楚了現有方案的問題以後，咱們首先試圖從優化搶佔判斷入手，當時想過不少辦法，好比：對最小運行時間進行優化，當在線搶佔離線的時候，忽略最小運行時間判斷？

在線搶佔離線
另外就是當在線搶佔離線，可是在線虛擬時間更大的時候，與離線互換虛擬時間？咱們想過不少辦法，有一些效果，可是仍是不能達到預期。

回過去看搶佔邏輯，若是搶佔的進程的調度類優先級更高的時候，是會立馬搶佔的。好比如今有個進程要運行，原來的CPU是空閒的，那麼這個進程是會當即執行的。而實際上這裏也是發生了搶佔，cfs調度類搶佔idle調度類。由於cfs調度類的優先級高於idle調度類的優先級。

所以，咱們試圖經過給離線進程專門設置一個專用調度類，來解決搶佔的問題。通過調研，咱們最終決定爲離線進程新加一個調度類：offline調度類，offline調度類的優先級低於cfs調度類，高於idle調度類，所以，cfs調度類能夠隨時搶佔offline調度類。下圖是咱們爲了支持離線調度類，支持的相關子系統，包括調度類基本功能支持，task_grouop支持，cpuacct, cpuset子系統支持，控制接口支持，等等。

支持離線調度類及相關子系統
在爲離線單獨設計了調度類解決了搶佔不及時的問題以後，咱們會發現一個問題，在咱們的方案中，在線是很強勢的，須要CPU的時候當即搶佔，那麼對離線來講就不利。咱們的方案目標，不只要讓離線不影響在線，還須要達到的目的是，要讓離線可以見縫插針的把空閒的CPU給利用上，達到提高整機CPU利用率的目的。那麼咱們是怎麼來作的呢？

3.如何讓離線高效的利用空閒CPU？
那麼就來看第二個問題，離線如何高效的利用空閒CPU？ 由於當有在線的時候，離線沒法得到CPU，所以要讓離線高效的得到CPU，第一個須要解決的是，離線如何去感知在線剩餘的算力？在線佔用100%的核上，是不該該調度離線過去運行的，由於離線一直得到不了CPU。在線佔用60%與在線佔用10%的CPU上，應該調度不一樣負載的離線去運行。

離線如何高效的利用空閒CPU？
所以，在線感知剩餘算力很關鍵，那麼怎麼作的呢？咱們最開始是若是負載均衡的時候，這個核有在線在運行就不調度離線過來，此種作法比較粗糙，波動很大效果不明顯。所以咱們對此進行了優化，離線算力算法以下：

(1)1-avg/T=離線負載算力

(2)avg隨之T不斷衰減，過一個T衰減成原來的1/2

(3)在線的運行時間不斷加入avg中

直接看文字很難懂，舉個例子；好比在線佔用CPU100%，T=1ms

那麼離線算力=1-(1/2+1/4+1/8+1/16+…)=0 ，也就是說算出來離線的算力是0，所以這個核上在線佔着100%的CPU。

若是在線佔用20%的CPU，T=1ms，那麼離線算力=1-(0.2/2+0.2/4+0.2/8+…)=0.8，所以，能夠遷移一些離線進程到這個核上。

另外，第二個是咱們引入了等待延遲，用於優化進程負載的計算。爲何要引入等待時間呢？由於咱們發現，若是用原來的算法，在業務限制某個CPU不讓離線運行時候，這個離線進程可能沒法被調走（好比說，四個CPU，四個離線，限制一個核，按照原來算法負載是均衡的）。另外咱們在測試中發現，離線在在線混部上來以後，離線的隊列等待時間會增大，縮短離線進程在隊列中的等待時間，是提升離線CPU佔有效率的關鍵。所以，咱們引入了隊列等待時間，經過等待時間算出一個翻倍因子，從而在負載均衡的時候，將最應該被調度的離線進程及時調度到空CPU上運行。

4、新方案效果
目前TLinux團隊混部方案的效果多個業務上都獲得了驗證，功能知足業務需求，在不影響在線業務的前提下，整機CPU利用率提高很是顯著，超過業務預期。下面是幾個典型場景的測試數據。

以下圖所示，在A測試場景中，模塊a一個用於統計頻率的模塊，對時延很是敏感。此業務不能混部，整機CPU利用率只有15%左右，業務嘗試過使用cgroup方案來混部，可是cgroup方案混部以後，對在線模塊a影響太大，致使錯誤次數陡增，所以此模塊一直不能混部。使用咱們提供的方案以後，能夠發現，CPU提高至60%，而且錯誤次數基本沒有變化。

業務場景A(a模塊)混部先後性能對比

業務場景A(a模塊)混部先後性能對比
在B測試場景中（模塊b是一個翻譯模塊，對時延很敏感），本來b模塊是不能混部的，業務嘗試過混部，可是由於離線混部上去以後對模塊b的影響很大，時延變長，因此一直不能混部。使用咱們的方案的效果以下圖所示，整機CPU利用率從20%提高至50%，而且對模塊沒有影響，時延基本上沒有變化。

業務場景B（b模塊）混部先後性能對比

業務場景B（b模塊）混部先後性能對比
模塊C對時延不像場景A，B那麼敏感，因此在使用咱們提供的方案以前，利用cgroup方案進行混部，CPU最高能夠達到40%。可是平臺再也不敢往上壓，由於再往上壓就會影響到在線c業務。以下圖所示，使用咱們的方案以後，平臺不斷往機器上添加離線業務，將機器CPU壓至90%的狀況下，c業務的各項指標仍是正常，並無受到影響。

業務場景C（c模塊）混部先後性能對比
TLinux團隊從今年三月份就開始在各業務場景中進行測試灰度，期間遇到了各類各樣的問題，不斷的優化完善。驗證的結果是：TLinux團隊混部方案在不影響在線業務的前提下，可以大幅度提高整機CPU的利用率，能爲公司節省大量的運營成本。目前TLinux團隊提供的公司內部內核，已經徹底支持TLinux團隊混部方案，公司不少業務已經開始使用TLinux團隊提供的混部方案。

PS：TLinux 團隊承載了騰訊公司級的服務器操做系統、內核、發行版及虛擬化研發任務，專一解決TLinux系統、內核、網絡、虛擬化平臺及文件系統的問題。在歷次的考驗中，承受住了服務器數量飆升的壓力，爲騰訊提供了穩定、持久的服務。