騰訊TLinux團隊提出了一套全新的混部方案，在不影響在線業務的前提下，對整機CPU利用率提升效果非常明顯，在有的業務場景下，整機CPU利用率甚至能提升至90%。
一、前言??

騰訊運營著海量的服務器，且近年的增長有加速的趨勢，成本問題日益嚴峻。其中，CPU利用率不高一直是影響整機效率的短板。

試想一下，如果能讓整機的CPU利用率翻一翻，是什么概念？

這相當于把一臺機器當兩臺使用，能為公司節省巨額的成本開銷。因此，各BG各業務都在想辦法提升整機CPU利用率。大家嘗試讓各種業務混部，試圖達到提高整機CPU利用率的目的。然而，方案的實際效果卻不盡如人意。現有的混部方案始終無法做到離線業務不影響在線，這種影響直接導致多數業務沒有辦法混部。

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

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

現有混部方案如何做？問題是什么？為什么現在CPU利用率還是不高？

TLinux團隊的方案是如何做的？為什么要這么做？

TLinux團隊的混部方案，真實業務使用效果如何？

二、現有方案

公司內部已有的混部方案總結來講主要有兩種：

????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利用率。

三、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上運行。

四、新方案效果

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

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

? ? ? ? ? ? ??

? ? ? ? ? ???業務場景A(a模塊)混部前后性能對比

在B測試場景中（模塊b是一個翻譯模塊，對時延很敏感），原本b模塊是不能混部的，業務嘗試過混部，但是因為離線混部上去之后對模塊b的影響很大，時延變長，所以一直不能混部。使用我們的方案的效果如下圖所示，整機CPU利用率從20%提升至50%，并且對模塊沒有影響，時延基本上沒有變化。

? ? ? ? ? ? ?

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

模塊C對時延不像場景A，B那么敏感，所以在使用我們提供的方案之前，利用cgroup方案進行混部，CPU最高可以達到40%。但是平臺不再敢往上壓，因為再往上壓就會影響到在線c業務。如下圖所示，使用我們的方案之后，平臺不斷往機器上添加離線業務，將機器CPU壓至90%的情況下，c業務的各項指標還是正常，并沒有受到影響。

? ? ? ? ? ?

C場景（c模塊）業務混部前后性能對比

TLinux團隊從今年三月份就開始在各業務場景中進行測試灰度，期間遇到了各種各樣的問題，不斷的優化完善。驗證的結果是：TLinux團隊混部方案在不影響在線業務的前提下，能夠大幅度提升整機CPU的利用率，能為公司節省大量的運營成本。目前TLinux團隊提供的公司內部內核，已經完全支持TLinux團隊混部方案，公司很多業務已經開始使用TLinux團隊提供的混部方案。

TLinux團隊簡介

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

本篇技術文章來源于公眾號「

?

---------下方更多精彩----------

活動推薦

總結

以上是生活随笔為你收集整理的腾讯成本优化黑科技：整机CPU利用率最高提升至90%的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。