可惡的CPU限制類(lèi)會(huì)影響容器的運(yùn)行，有時(shí)為了避免CPU限制類(lèi)，需要犧牲容器分發(fā)密度。

我們?cè)O(shè)計(jì)的 CPU Burst 技術(shù)既能保證容器運(yùn)行服務(wù)質(zhì)量，又不降低容器部署密度。CPU Burst 特性已合入 Linux 5.14，Anolis OS 8.2、Alibaba Cloud Linux2、Alibaba Cloud Linux3 也都支持 CPU Burst 特性。

在 K8s 容器調(diào)度中，容器的 CPU 資源上限是由 CPU limits 參數(shù)指定。設(shè)置 CPU 資源上限可以限制個(gè)別容器消耗過(guò)多的 CPU 運(yùn)行時(shí)間，并確保其他容器拿到足夠的 CPU 資源。CPU limits 限制在 Linux 內(nèi)核中是用 CPU Bandwidth Controller 實(shí)現(xiàn)的，它通過(guò) CPU 限流限制 cgroup 的資源消耗。所以當(dāng)一個(gè)容器中的進(jìn)程使用了超過(guò) CPU limits 的資源的時(shí)候，這些進(jìn)程就會(huì)被 CPU 限流，他們使用的 CPU 時(shí)間就會(huì)受到限制，進(jìn)程中一些關(guān)鍵的延遲指標(biāo)就會(huì)變差。

面對(duì)這種情況，我們應(yīng)該怎么辦呢？一般情況下，我們會(huì)結(jié)合這個(gè)容器日常峰值的 CPU 利用率并乘以一個(gè)相對(duì)安全的系數(shù)來(lái)設(shè)置這個(gè)容器的 CPU limits ，這樣我們既可以避免容器因?yàn)橄蘖鞫鴮?dǎo)致的服務(wù)質(zhì)量變差，同時(shí)也可以兼顧 CPU 資源的利用。舉個(gè)簡(jiǎn)單的例子，我們有一個(gè)容器，他日常峰值的 CPU 使用率在 250% 左右，那么我們就把容器 CPU limits 設(shè)置到 400% 來(lái)保證容器服務(wù)質(zhì)量，此時(shí)容器的 CPU 利用率是 62.5%（250%/400%）。

然而生活真的那么美好嗎？顯然不是！CPU 限流的出現(xiàn)比預(yù)期頻繁了很多。怎么辦？似乎看上去我們只能繼續(xù)調(diào)大 CPU limits 來(lái)解決這個(gè)問(wèn)題。很多時(shí)候，當(dāng)容器的 CPU limits 被放大 5~10 倍的時(shí)候，這個(gè)容器的服務(wù)質(zhì)量才得到了比較好的保障，相應(yīng)的這時(shí)容器的總 CPU 利用率只有 10%~20%。所以為了應(yīng)對(duì)可能的容器 CPU 使用高峰，容器的部署密度必須大大降低。

歷史上人們?cè)?CPU Bandwidth Controller 中修復(fù)了一些 BUG 導(dǎo)致的 CPU 限流問(wèn)題，我們發(fā)現(xiàn)當(dāng)前非預(yù)期限流是由于 100ms 級(jí)別 CPU 突發(fā)使用引起，并且提出 CPU Burst 技術(shù)允許一定的 CPU 突發(fā)使用，避免平均 CPU 利用率低于限制時(shí)的 CPU 限流。在云計(jì)算場(chǎng)景中，CPU Burst 技術(shù)的價(jià)值有：

1. 不提高 CPU 配置的前提下改善 CPU 資源服務(wù)質(zhì)量；
2. 允許資源所有者不犧牲資源服務(wù)質(zhì)量降低 CPU 資源配置，提升 CPU 資源利用率；
3. 降低資源成本（TCO, Total Cost of Ownership）。

你看到的 CPU 利用率不是全部真相

秒級(jí) CPU 利用率不能反映 Bandwidth Controller 工作的 100ms 級(jí)別 CPU 使用情況，是導(dǎo)致非預(yù)期 CPU 限流出現(xiàn)的原因。

Bandwidth Controller 適用于 CFS 任務(wù)，用 period 和 quota 管理 cgroup 的 CPU 時(shí)間消耗。若 cgroup 的 period 是 100ms quota 是 50ms，cgroup 的進(jìn)程每 100ms 周期內(nèi)最多使用 50ms CPU 時(shí)間。當(dāng) 100ms 周期的 CPU 使用超過(guò) 50ms 時(shí)進(jìn)程會(huì)被限流，cgroup 的 CPU 使用被限制到 50%。

CPU 利用率是一段時(shí)間內(nèi) CPU 使用的平均，以較粗的粒度統(tǒng)計(jì) CPU 的使用需求，CPU 利用率趨向穩(wěn)定；當(dāng)觀(guān)察的粒度變細(xì)，CPU 使用的突發(fā)特征更明顯。以 1s 粒度和 100ms 粒度同時(shí)觀(guān)測(cè)容器負(fù)載運(yùn)行，當(dāng)觀(guān)測(cè)粒度是 1s 時(shí) CPU 利用率的秒級(jí)平均在 250% 左右，而在 Bandwidth Controller 工作的 100ms 級(jí)別觀(guān)測(cè) CPU 利用率的峰值已經(jīng)突破 400% 。

根據(jù)秒級(jí)觀(guān)察到的 CPU 利用率 250% 設(shè)置容器 quota 和 period 分別為 400ms 和 100ms ，容器進(jìn)程的細(xì)粒度突發(fā)被 Bandwidth Controller 限流，容器進(jìn)程的 CPU 使用受到影響。

如何改善

我們用 CPU Burst 技術(shù)來(lái)滿(mǎn)足這種細(xì)粒度 CPU 突發(fā)需求，在傳統(tǒng)的 CPU Bandwidth Controller quota 和 period 基礎(chǔ)上引入 burst 的概念。當(dāng)容器的 CPU 使用低于 quota 時(shí)，可用于突發(fā)的 burst 資源累積下來(lái)；當(dāng)容器的 CPU 使用超過(guò) quota，允許使用累積的 burst 資源。最終達(dá)到的效果是將容器更長(zhǎng)時(shí)間的平均 CPU 消耗限制在 quota 范圍內(nèi)，允許短時(shí)間內(nèi)的 CPU 使用超過(guò)其 quota。

如果用 Bandwidth Controller 算法來(lái)管理休假，假期管理的周期（period）是一年，一年里假期的額度是 quota ，有了 CPU Burst 技術(shù)之后今年修不完的假期可以放到以后來(lái)休了。

在容器場(chǎng)景中使用 CPU Burst 之后，測(cè)試容器的服務(wù)質(zhì)量顯著提升。觀(guān)察到 RT 均值下降 68%（從 30+ms 下降到 9.6ms ）；99% RT 下降 94.5%（從 500+ms 下降到 27.37ms ）。

CPU Bandwidth Controller 的保證

使用 CPU Bandwidth Controller 可以避免某些進(jìn)程消耗過(guò)多 CPU 時(shí)間，并確保所有需要 CPU 的進(jìn)程都拿到足夠的 CPU 時(shí)間。之所以有這樣好的穩(wěn)定性保證，是因?yàn)楫?dāng) Bandwidth Controller 設(shè)置滿(mǎn)足下述情況時(shí)，

有如下的調(diào)度穩(wěn)定性約束：

其中，

是第 i 個(gè) cgroup 的 quota，是一個(gè) period 內(nèi)該 cgroup 的 CPU 需求。Bandwidth Controller 對(duì)每個(gè)周期分別做 CPU 時(shí)間統(tǒng)計(jì)，調(diào)度穩(wěn)定性約束保證在一個(gè) period 內(nèi)提交的全部任務(wù)都能在該周期內(nèi)處理完；對(duì)每個(gè) CPU cgroup 而言，這意味著任何時(shí)候提交的任務(wù)都能在一個(gè) period 內(nèi)執(zhí)行完，即任務(wù)實(shí)時(shí)性約束：

不管任務(wù)優(yōu)先級(jí)如何，最壞情況下任務(wù)執(zhí)行時(shí)間（WCET, Worst-Case Execution Time）不超過(guò)一個(gè) period。

假如持續(xù)出現(xiàn)

調(diào)度器穩(wěn)定性被打破，在每個(gè) period 都有任務(wù)積攢下來(lái)，新提交的作業(yè)執(zhí)行時(shí)間不斷增加。

使用 CPU Burst 的影響

出于改善服務(wù)質(zhì)量的需要，我們使用 CPU Burst 允許突發(fā)的 CPU 使用之后，對(duì)調(diào)度器的穩(wěn)定性產(chǎn)生什么影響？答案是當(dāng)多個(gè) cgroup 同時(shí)突發(fā)使用 CPU，調(diào)度器穩(wěn)定性約束和任務(wù)實(shí)時(shí)性保證有可能被打破。這時(shí)候兩個(gè)約束得到保證的概率是關(guān)鍵，如果兩個(gè)約束得到保證的概率很高，對(duì)大多數(shù)周期來(lái)任務(wù)實(shí)時(shí)性都得到保證，可以放心大膽使用 CPU Burst；如果任務(wù)實(shí)時(shí)性得到保證的概率很低，這時(shí)候要改善服務(wù)質(zhì)量不能直接使用 CPU Burst，應(yīng)該先降低部署密度提高 CPU 資源配置。

于是下一個(gè)關(guān)心的問(wèn)題是，怎么計(jì)算特定場(chǎng)景下兩個(gè)約束被打破的概率。

評(píng)估影響大小

定量計(jì)算可以定義成經(jīng)典的排隊(duì)論問(wèn)題，并且用蒙特卡洛模擬方法求解。定量計(jì)算的結(jié)果表明，判斷當(dāng)前場(chǎng)景是否可以使用 CPU Burst 的主要影響因素是平均 CPU 利用率和 cgroup 數(shù)目。CPU 利用率越低，或者 cgroup 數(shù)目越多，兩個(gè)約束越不容易被打破可以放心使用 CPU Burst。反之如果 CPU 利用率很高或者 cgroup 數(shù)目較少，要消除 CPU 限流對(duì)進(jìn)程執(zhí)行的影響，應(yīng)該降低部署提高配置再使用 CPU Burst。

問(wèn)題定義是：一共有 m 個(gè) cgroup，每個(gè) cgroup 的 quota 限制為 1/m，每個(gè) cgroup 在每個(gè)周期產(chǎn)生的計(jì)算需求（CPU 利用率）服從某個(gè)具體分布，這些分布是相互獨(dú)立的。假設(shè)任務(wù)在每個(gè)周期的開(kāi)始到達(dá)，如果該周期內(nèi)的 CPU 需求超過(guò) 100%，當(dāng)前周期任務(wù) WCET 超過(guò) 1 個(gè) period，超過(guò)的部分累積下來(lái)和下個(gè)周期新產(chǎn)生的 CPU 需求一起在下個(gè)需求處理。輸入是 cgroup 的數(shù)目 m 和每個(gè) CPU 需求滿(mǎn)足的具體分布，輸出是每個(gè)周期結(jié)束 WCET > period 的概率和 WCET 期望。

以輸入的 CPU 需求為帕累托分布、m=10/20/30 的結(jié)果為例進(jìn)行說(shuō)明。選擇帕累托分布進(jìn)行說(shuō)明的原因是它產(chǎn)生比較多的長(zhǎng)尾 CPU 突發(fā)使用，容易產(chǎn)生較大影響。表格中數(shù)據(jù)項(xiàng)的格式為

其中

越接近 1 越好，

概率越低越好。

u_avg

m=10

m=20

m=30

10%

1.0000/0.00%

1.0000/0.00%

1.0000/0.00%

30%

1.0000/0.00%

1.0000/0.00%

1.0000/0.00%

50%

1.0003/0.03%

1.0000/0.00%

1.0000/0.00%

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%

結(jié)果跟直覺(jué)是吻合的。一方面，CPU 需求（CPU 利用率）越高，CPU 突發(fā)越容易打破穩(wěn)定性約束，造成任務(wù) WCET 期望變長(zhǎng)。另一方面，CPU 需求獨(dú)立分布的 cgroup 數(shù)目越多，它們同時(shí)產(chǎn)生 CPU 突發(fā)需求的可能性越低，調(diào)度器穩(wěn)定性約束越容易保持，WCET 的期望越接近 1 個(gè) period。

場(chǎng)景和參數(shù)設(shè)定

我們?cè)O(shè)定整個(gè)系統(tǒng)存在 m 個(gè) cgroup，每個(gè) cgroup 公平瓜分總量為 100% 的 CPU 資源，即 quota=1/m。每個(gè) cgoup 按相同規(guī)律（獨(dú)立同分布）產(chǎn)生計(jì)算需求并交給 CPU 執(zhí)行。

我們參考排隊(duì)論的模型，將每個(gè) cgroup 視為一位顧客，CPU 即為服務(wù)臺(tái)，每位顧客的服務(wù)時(shí)間受到 quota 的限制。為了簡(jiǎn)化模型，我們離散化地定義所有顧客的到達(dá)時(shí)間間隔為常數(shù)，然后在該間隔內(nèi) CPU 最多能服務(wù) 100% 的計(jì)算需求，這個(gè)時(shí)間間隔即為一個(gè)周期。

然后我們需要定義每位顧客在一個(gè)周期內(nèi)的服務(wù)時(shí)間。我們假定顧客產(chǎn)生的計(jì)算需求是獨(dú)立同分布的，其平均值是自身 quota 的 u_avg 倍。顧客在每個(gè)周期得不到滿(mǎn)足的計(jì)算需求會(huì)一直累積，它每個(gè)周期向服務(wù)臺(tái)提交的服務(wù)時(shí)間取決于它自身的計(jì)算需求和系統(tǒng)允許的最大 CPU time（即其 quota 加上之前周期累積的 token）。

最后，CPU Burst 技術(shù)中有一項(xiàng)可調(diào)參數(shù) buffer，表示允許累積的 token 上限。它決定了每個(gè) cgroup 的瞬時(shí)突發(fā)能力，我們將其大小用 quota 的 b 倍表示。

我們對(duì)上述定義的參數(shù)作出了如下設(shè)置：

參數(shù)

描述

值

distribution

計(jì)算需求產(chǎn)生的分布

負(fù)指數(shù)、帕累托

u_avg

平均產(chǎn)生的計(jì)算需求

10%-90%

m

cgroup（容器）個(gè)數(shù)

10、20、30

b

令牌桶的buffer大?。ㄏ鄬?duì)于其quota的倍率）

100%、200%、∞

負(fù)指數(shù)分布是排隊(duì)論模型中最常見(jiàn)、最多被使用的分布之一。其密度函數(shù)為

其中

帕累托分布是計(jì)算機(jī)調(diào)度系統(tǒng)中比較常見(jiàn)的分布，且它能夠模擬出較大的延遲長(zhǎng)尾，從而體現(xiàn) CPU Burst 的效果。其密度函數(shù)為：

為了抑制尾部的概率分布使其不至于過(guò)于夸張，我們?cè)O(shè)置了：

此時(shí)當(dāng) u_avg=30% 時(shí)可能產(chǎn)生的最大計(jì)算需求約為 500%。

數(shù)據(jù)展示

按上述參數(shù)設(shè)置進(jìn)行蒙特卡洛模擬的結(jié)果如下所示。我們將第一張（WCET 期望）的圖表 y 軸進(jìn)行顛倒來(lái)更好地符合直覺(jué)。同樣地，第二張圖表（WCET 等于 1 的概率）表示調(diào)度的實(shí)時(shí)性得到保證的概率，以百分制表示。

負(fù)指數(shù)分布

帕累托分布

結(jié)論

一般來(lái)說(shuō)，u_avg（計(jì)算需求的負(fù)荷）越高，m（cgroup 數(shù)量）越少，WCET 越大。前者是顯然的結(jié)論，后者是因?yàn)楠?dú)立同分布情況下任務(wù)數(shù)量越多，整體產(chǎn)生需求越趨于平均，超出 quota 需求的任務(wù)和低于 quota 從而空出 cpu 時(shí)間的任務(wù)更容易互補(bǔ)。

提高 buffer 會(huì)使得 CPU Burst 發(fā)揮更好的效果，對(duì)單個(gè)任務(wù)的優(yōu)化收益更明顯；但同時(shí)也會(huì)增大 WCET，意味著增加對(duì)相鄰任務(wù)的干擾。這也是符合直覺(jué)的結(jié)論。

在設(shè)置 buffer 大小時(shí)，我們建議根據(jù)具體業(yè)務(wù)場(chǎng)景的計(jì)算需求（包括分布和均值）和容器數(shù)量，以及自身需求來(lái)決定。如果希望增加整體系統(tǒng)的吞吐量，以及在平均負(fù)荷不高的情況下優(yōu)化容器性能，可以增大 buffer；反之如果希望保證調(diào)度的穩(wěn)定性和公平性，在整體負(fù)荷較高的情況下減少容器受到的影響，可以適當(dāng)減小 buffer。

一般而言，在低于 70% 平均 CPU 利用率的場(chǎng)景中，CPU Burst 不會(huì)對(duì)相鄰容器造成較大影響。

模擬工具與使用方法

說(shuō)完了枯燥的數(shù)據(jù)和結(jié)論，接下來(lái)介紹可能有許多讀者關(guān)心的問(wèn)題：CPU Burst 會(huì)不會(huì)對(duì)我的實(shí)際業(yè)務(wù)場(chǎng)景造成影響？為了解決這個(gè)疑惑，我們將蒙特卡洛模擬方法所用工具稍加改造，從而能幫助大家在自己的實(shí)際場(chǎng)景中測(cè)試具體的影響～

工具可以在這里獲?。?/p>

詳細(xì)的使用說(shuō)明也附在 README 中了，下面讓我們看一個(gè)具體的例子吧。

小 A 想在他的服務(wù)器上部署 10 臺(tái)容器用于相同業(yè)務(wù)。為了獲取準(zhǔn)確的測(cè)量數(shù)據(jù)，他先啟動(dòng)了一臺(tái)容器正常運(yùn)行業(yè)務(wù)，綁定到名為 cg1 的 cgroup 中，不設(shè)限流以獲取該業(yè)務(wù)的真實(shí)表現(xiàn)。

然后調(diào)用 進(jìn)行數(shù)據(jù)采集：（演示效果只采集了 1000 次，實(shí)際建議有條件的情況下采集次數(shù)越大越好）

這些數(shù)據(jù)被存儲(chǔ)到了./data 中。最后輸出的提示說(shuō)明該業(yè)務(wù)平均占用了約 6.5% 的 CPU，部署 10 臺(tái)容器的情況下總的平均 CPU 利用率約為 65%。（PS：方差數(shù)據(jù)同樣打印出來(lái)作為參考，也許方差越大，越能從 CPU Burst 中受益哦）

接下來(lái)，他利用 計(jì)算配置 10 個(gè) 和 cg1 相同場(chǎng)景的 cgroup 時(shí)，將 buffer 設(shè)置為 200% 的影響：

根據(jù)模擬結(jié)果，開(kāi)啟 CPU Burst 功能對(duì)該業(yè)務(wù)場(chǎng)景下的容器幾乎沒(méi)有負(fù)面影響，小 A 可以放心使用啦。

想要進(jìn)一步了解該工具的用法，或是出于對(duì)理論的興趣去改變分布查看模擬結(jié)果，都可以訪(fǎng)問(wèn)上面的倉(cāng)庫(kù)鏈接找到答案～

關(guān)于作者

常懷鑫（一齋），阿里云內(nèi)核組工程師，擅長(zhǎng) CPU 調(diào)度領(lǐng)域。

丁天琛(鷹羽)，2021 年加入阿里云內(nèi)核組，目前在調(diào)度領(lǐng)域等方面學(xué)習(xí)研究。