CPU Burst有副作用嗎？讓數學來回答！| 龍蜥技術

編者按：CPU Burst 特性已合入 Linux 5.14，Anolis OS 8.2、Alibaba Cloud Linux2、Alibaba Cloud Linux3也都支援CPU Burst特性。

在系列文章的上篇中，我們讨論了 讓人讨厭的 CPU 限流 ，它會影響運作在容器中的應用的一些關鍵名額。為了避免限流的出現，有時我們不得不犧牲容器部署密度，進而導緻資源浪費的産生。在解決方案部分，我們也介紹了新的CPU Burst 技術，通過這一技術，我們既能保證容器運作服務品質，又不降低容器部署密度。聽起來有點像個銀彈啊？那麼，使用CPU Burst的副作用是什麼？是否有不适用的場景呢？為了回答這個問題，本文将介紹CPU Burst打破的排程保證，以及CPU Burst影響評估。盡管這些CPU突發的使用造成的CPU使用差異在CPU使用率上很多時候不明顯，但是我們仍然關心這種改變的影響。當然，結論是明确的：CPU Burst的負面影響完全可以忽略。僅在CPU使用率高達70%的環境裡CPU Burst開始影響關鍵名額，而我相信大家日常生産環境的CPU使用率都遠遠低于這個水準。

CPU Bandwidth Controller的保證

使用CPU Bandwidth Controller可以避免某些程序消耗過多CPU時間，并確定所有需要CPU的程序都拿到足夠的CPU時間。之是以有這樣好的穩定性保證，是因為當Bandwidth Controller設定滿足

時，有如下的排程穩定性限制：

其中

是第i個cgroup的quota，是一個period内該cgroup的CPU需求。Bandwidth Controller對每個周期分别做CPU時間統計，排程穩定性限制保證在一個period内送出的全部任務都能在該周期内處理完；對每個CPU cgroup而言，這意味着任何時候送出的任務都能在一個period内執行完，即任務實時性限制：

不管任務優先級如何，最壞情況下任務執行時間（WCET, Worst-Case Execution Time）不超過一個period。

假如持續出現

排程器穩定性被打破，在每個period都有任務積攢下來，新送出的作業執行時間不斷增加。

使用CPU Burst的影響

出于改善服務品質的需要，我們使用CPU Burst允許突發的CPU使用之後，對排程器的穩定性産生什麼影響？答案是當多個cgroup同時突發使用CPU，排程器穩定性限制和任務實時性保證有可能被打破。這時候兩個限制得到保證的機率是關鍵，如果兩個限制得到保證的機率很高，對大多數周期來任務實時性都得到保證，可以放心大膽使用CPU Burst；如果任務實時性得到保證的機率很低，這時候要改善服務品質不能直接使用CPU Burst，應該先降低部署密度提高CPU資源配置。于是下一個關心的問題是，怎麼計算特定場景下兩個限制被打破的機率。

評估影響大小

定量計算可以定義成經典的排隊論問題，并且用蒙特卡洛模拟方法求解。定量計算的結果表明，判斷目前場景是否可以使用CPU Burst的主要影響因素是平均CPU使用率和cgroup數目。CPU使用率越低，或者cgroup數目越多，兩個限制越不容易被打破可以放心使用CPU Burst。反之如果CPU使用率很高或者cgroup數目較少，要消除CPU限流對程序執行的影響，應該降低部署提高配置再使用CPU Burst。問題定義是：一共有m個cgroup，每個cgroup的quota限制為1/m，每個cgroup在每個周期産生的計算需求（CPU使用率）服從某個具體分布，這些分布是互相獨立的。假設任務在每個周期的開始到達，如果該周期内的CPU需求超過100%，目前周期任務WCET超過1個period，超過的部分累積下來和下個周期新産生的CPU需求一起在下個需求處理。輸入是cgroup的數目m和每個CPU需求滿足的具體分布，輸出是每個周期結束WCET > period的機率和WCET期望。使用蒙特卡洛模拟求解過程省略，詳細請關注後續系列文章。以輸入的CPU需求為帕累托分布、m=10/20/30的結果為例進行說明。選擇帕累托分布進行說明的原因是它産生比較多的長尾CPU突發使用，容易産生較大影響。表格中資料項的格式為

，其中

越接近1越好，

機率越低越好。

u_avg	m=10	m=20	m=30
10%	1.0000/0.00%
30%
50%	1.0003/0.03%
70%	1.0077/0.66%	1.0013/0.12%	1.0004/0.04%
90%	1.4061/19.35%	1.1626/10.61%	1.0867/6.52%

結果跟直覺是吻合的。一方面，CPU需求（CPU使用率）越高，CPU突發越容易打破穩定性限制，造成任務WCET期望變長。另一方面，CPU需求獨立分布的cgroup數目越多，它們同時産生CPU突發需求的可能性越低，排程器穩定性限制越容易保持，WCET的期望越接近1個period。

後續

看完本文相信您對CPU Burst的影響已經有了定性了解。如果希望對評估方法有更多了解，請期待系列文章的下篇。

關于作者

常懷鑫（一齋），阿裡雲核心組工程師，擅長CPU排程領域。

丁天琛(鷹羽)，2021年加入阿裡雲核心組，目前在排程領域等方面學習研究

——完——

加入龍蜥社群

加入微信群：添加社群助理-龍蜥社群小龍（微信：openanolis_assis），備注【龍蜥】拉你入群；加入釘釘群：掃描下方釘釘群二維碼。歡迎開發者/使用者加入龍蜥OpenAnolis社群交流，共同推進龍蜥社群的發展，一起打造一個活躍的、健康的開源作業系統生态！

龍蜥社群釘釘交流群 龍蜥社群-小龍

關于龍蜥社群

龍蜥社群是由企事業機關、高等院校、科研機關、非營利性組織、個人等按照自願、平等、開源、協作的基礎上組成的非盈利性開源社群。龍蜥社群成立于2020年9月，旨在建構一個開源、中立、開放的Linux上遊發行版社群及創新平台。

短期目标是開發Anolis OS作為CentOS替代版，重新建構一個相容國際Linux主流廠商發行版。中長期目标是探索打造一個面向未來的作業系統，建立統一的開源作業系統生态，孵化創新開源項目，繁榮開源生态。

龍蜥OS 8.4已釋出，支援x86_64和ARM64架構，完善适配Intel、飛騰、海光、兆芯、鲲鵬晶片。

歡迎下載下傳：

https://openanolis.cn/download

加入我們，一起打造面向未來的開源作業系統！

Https：//openanolis.cn