關(guān)于提升 CPU 資源隔離的混部技術(shù)細(xì)節(jié)

「概述」

在數(shù)據(jù)中心服務(wù)器或者各種云集群（后續(xù)簡(jiǎn)稱集群）的生產(chǎn)環(huán)境上，部署著很多日常的在線（LC, Latency-critical service）服務(wù)。這類服務(wù)具有一定的負(fù)載不確定性，集群需要將服務(wù)器的平均利用率保持在較低的水平，使得當(dāng)突發(fā)流量帶來請(qǐng)求洪峰時(shí)，仍有充足資源用于計(jì)算與響應(yīng)，從而避免了請(qǐng)求堆積造成的服務(wù)癱瘓，保證用戶能夠擁有良好的體驗(yàn)。但是這樣做造成了大批的空閑資源浪費(fèi)，提高了維護(hù)成本。在這種條件下想要提高資源利用率，一種直接的方式是在線服務(wù)負(fù)載較低時(shí)，部署另一種任務(wù)，提高資源的利用效率。這類應(yīng)用不要求有極高的響應(yīng)速度，但是將耗費(fèi)較大的計(jì)算資源，我們稱之為離線任務(wù)（BE, Best-effort batch）。因此各大云服務(wù)廠商引入在線離線混合部署方案來提升服務(wù)器的資源利用率，以降低云的運(yùn)營(yíng)成本。但事物的發(fā)展是具有兩面性的，混合部署也不例外，提升資源利用率的同時(shí)也會(huì)帶來資源隔離的問題。

本文詳細(xì)介紹并分享關(guān)于提升 CPU 資源隔離的混部技術(shù)細(xì)節(jié)：

-「CPU 搶占」：當(dāng)一臺(tái)服務(wù)上同時(shí)存在在線服務(wù)、離線服務(wù)，如果不對(duì)離線服務(wù)加以限制，離線服務(wù)將會(huì)盡可能多的占用資源，從而增加在線任務(wù)的相應(yīng)時(shí)延。所以本方案在同一個(gè)核上的在線（LC）服務(wù)能夠搶占?jí)褐齐x線（BE）服務(wù),最終保證在線服務(wù)的 QoS.

-「SMT 隔離控制」：同一個(gè)物理 CPU 的超線程共享核心的硬件資源，如 Cache 和計(jì)算單元。當(dāng)在線任務(wù)和離線任務(wù)同時(shí)運(yùn)行在一對(duì)超線程上時(shí)，會(huì)因?yàn)橛布Y源爭(zhēng)搶出現(xiàn)相互干擾的情況。此時(shí)需要驅(qū)離離線任務(wù)，該 HT 核進(jìn)入 idle。

在混部場(chǎng)景 CPU 在離線調(diào)度的實(shí)現(xiàn)中，存在在線作業(yè)時(shí)，我們會(huì)對(duì)離線任務(wù)進(jìn)行 throttle，以確保在線任務(wù)的 CPU 資源供應(yīng)。當(dāng)開啟 HT 后，我們會(huì)驅(qū)離同時(shí)運(yùn)行在同一個(gè)物理核且運(yùn)行在不同邏輯核的離線任務(wù)。本方案的設(shè)計(jì)目標(biāo)是保證在線業(yè)務(wù)服務(wù)質(zhì)量前提下實(shí)現(xiàn)資源利用率最大化提升。因此本方案的設(shè)計(jì)是圍繞如何提升 CPU 資源利用率和保障在線業(yè)務(wù)的響應(yīng)速度展開。主要包括以下兩個(gè)子特性的設(shè)計(jì)：

特性一、CPU 搶占

「（1）在線任務(wù)搶占時(shí)延保證」

為了保證在線任務(wù)能夠快速搶占離線任務(wù)，我們默認(rèn)會(huì)將離線任務(wù)的調(diào)度策略設(shè)置為SCHED_IDLE，而在線任務(wù)調(diào)度策略不做修改（通常情況下在線任務(wù)的調(diào)度策略為SCHED_OTHER），當(dāng)在線任務(wù)搶占離線任務(wù)時(shí)，可以快速搶占，不受限于 sched_min_granularity_ns 和sched_wakeup_granularity_ns機(jī)制限制。

「（2）在線任務(wù)絕對(duì)壓制離線任務(wù)」

當(dāng)在線任務(wù)在運(yùn)行時(shí)，離線任務(wù)需要停止運(yùn)行，以避免和在線任務(wù)搶占 CPU 資源，因此在線任務(wù)需要盡可能地壓制離線任務(wù)，通過引入 throttle 機(jī)制對(duì)離線任務(wù)進(jìn)行限制, 在一個(gè) CPU 上同時(shí)存在在線和離線任務(wù)的場(chǎng)景下，將離線組對(duì)應(yīng)的cfs_rq 添加到一個(gè)全局 percpu 鏈表throttle_list，從而將 CPU 資源完全讓給在線任務(wù)。具體流程如下:

圖 1 離線任務(wù) throttle

特性二、SMT 隔離控制

由于同一個(gè)物理 CPU 上的超線程共享核心的硬件資源，比如 Cache 和計(jì)算單元。當(dāng)在線任務(wù)和離線任務(wù)同時(shí)運(yùn)行在一對(duì)超線程上時(shí)，相互之間會(huì)因?yàn)橛布Y源爭(zhēng)搶，而出現(xiàn)相互干擾的情況。而 CFS 在設(shè)計(jì)時(shí)完全沒有考慮這個(gè)問題。其結(jié)果是，在混部場(chǎng)景中，在線業(yè)務(wù)的性能受損。實(shí)際測(cè)試使用 CPU 密集型 benchmark，因超線程導(dǎo)致的性能干擾可達(dá) 40%+。雖然 Linux 5.14 版本已經(jīng)合入了 Core Scheduing，但該特性本身是為了解決利用 SMT 側(cè)信道攻擊的，避免互相不被信任的兩個(gè)進(jìn)程工作在一個(gè)核的不同 SMT 上。其有幾點(diǎn)缺陷是我們不用該特性做 SMT 驅(qū)離的理由，首先其設(shè)計(jì)和實(shí)現(xiàn)過重，開銷較大（比如 core 級(jí)別的 rq lock）。其次其并不支持組調(diào)度功能，是以進(jìn)程為粒度進(jìn)行隔離，而我們的需求是希望對(duì)在線任務(wù)和離線任務(wù)進(jìn)行隔離。為了盡可能減輕這種競(jìng)爭(zhēng)的影響，我們讓一個(gè)核執(zhí)行在線任務(wù)的時(shí)候，它對(duì)應(yīng)的 MT 上不再運(yùn)行離線任務(wù)；或者當(dāng)一個(gè)核上有離線任務(wù)運(yùn)行的時(shí)候，在線任務(wù)調(diào)度到了其對(duì)應(yīng)的 HT 上時(shí)，會(huì)由該在線任務(wù)發(fā)送 IPI 將離線任務(wù)驅(qū)趕走。保證在線任務(wù)運(yùn)行時(shí)不被干擾。如下圖所示：

圖 2 SMT 隔離控制方案設(shè)計(jì)

方案需要重點(diǎn)解決的問題

（1）離線任務(wù) kill boost

當(dāng)在線任務(wù) 100% 運(yùn)行時(shí)，kill 一個(gè)離線任務(wù)，此時(shí)離線任務(wù)需要得到運(yùn)行以釋放一些系統(tǒng)資源，但是因?yàn)楫?dāng)前方案在線任務(wù)會(huì)對(duì)離線任務(wù)產(chǎn)生絕對(duì)壓制，為此引入 kill boost 解決此問題;

離線任務(wù)所在 group 為離線 group，root group 為在線任務(wù)，當(dāng)對(duì)一個(gè)離線任務(wù)進(jìn)行 kill 時(shí)，將對(duì)應(yīng)的離線任務(wù)移入到 root group, 從而使離線任務(wù)變?yōu)樵诰€任務(wù)，能夠得到機(jī)會(huì)運(yùn)行從而釋放資源。

（2）優(yōu)先級(jí)反轉(zhuǎn)

如果在線任務(wù)和離線任務(wù)之間有共享資源(比如內(nèi)核中的一些公共數(shù)據(jù))，當(dāng)離線任務(wù)因訪問共享資源而拿到鎖(抽象一下，不一定是鎖)后，如果被“絕對(duì)壓制”，一直無法運(yùn)行，當(dāng)在線任務(wù)也需要訪問該共享資源，而等待相應(yīng)的鎖時(shí)，優(yōu)先級(jí)反轉(zhuǎn)出現(xiàn)，導(dǎo)致死鎖(長(zhǎng)時(shí)間阻塞也可能)。優(yōu)先級(jí)反轉(zhuǎn)是調(diào)度模型中需要考慮的一個(gè)經(jīng)典問題。

目前該方案主要分為兩個(gè)模塊，優(yōu)先級(jí)反轉(zhuǎn)檢測(cè)和優(yōu)先級(jí)反轉(zhuǎn)處理：

「優(yōu)先級(jí)反轉(zhuǎn)檢測(cè)」：出現(xiàn)優(yōu)先級(jí)反轉(zhuǎn)的前提的是，在線任務(wù)長(zhǎng)時(shí)間 100%占用 CPU，導(dǎo)致離線任務(wù)被壓制無法釋放資源導(dǎo)致，基于這一特點(diǎn)，我們可以通過檢測(cè)離線任務(wù)是否長(zhǎng)時(shí)間沒有得到運(yùn)行來判斷是否可能存在優(yōu)先級(jí)反轉(zhuǎn)流程。

「優(yōu)先級(jí)反轉(zhuǎn)處理」：當(dāng)檢測(cè)到優(yōu)先級(jí)反轉(zhuǎn)時(shí)，對(duì)應(yīng) CPU 上的離線任務(wù)不再被在線任務(wù)壓制, 可以正常運(yùn)行，在返回用戶態(tài)之前會(huì)進(jìn)入睡眠流程，其中每次睡眠時(shí)間可以根據(jù)參數(shù)進(jìn)行設(shè)置。當(dāng) CPU 處理完隊(duì)列中的所有任務(wù)時(shí)，就會(huì)進(jìn)入 idle, 此時(shí)代表當(dāng)前 CPU 恢復(fù)正常情況。代表優(yōu)先級(jí)反轉(zhuǎn)問題已經(jīng)解決，進(jìn)入正常的在離線混跑邏輯。

任務(wù)管理

容器混部場(chǎng)景中，在離線任務(wù)是以 Cgroup 組的形式進(jìn)行配置的，所以我們提供了 Cgroup 接口進(jìn)行任務(wù)管理。對(duì)應(yīng)路徑為：

/sys/fs/cgroup/cpu/xxx/cpu.qos_level

其中，cpu.qos_level文件代表當(dāng)前 group 里任務(wù)的在離線屬性，默認(rèn)值為 0，代表該任務(wù)為在線任務(wù)組; 若值為-1 則代表為離線任務(wù)組

于是，如果想要對(duì)任務(wù)進(jìn)行管理，可以在工作節(jié)點(diǎn)上創(chuàng)建離線任務(wù)組，將離線任務(wù)的 pid 寫入到該組的 task 中，再設(shè)置對(duì)應(yīng)的cpu.qos_level文件：

# echo  > /sys/fs/cgroup/cpu/xxx/tasks# echo -1 > /sys/fs/cgroup/cpu/xxx/cpu.qos_level

通過混部引擎 rubik 進(jìn)行管理

在容器混合部署場(chǎng)景下，混部引擎 rubik 可以自動(dòng)感知用戶配置的業(yè)務(wù)優(yōu)先級(jí)并配置其 CPU 優(yōu)先級(jí)屬性，rubik 具體的介紹和使用詳見《openEuler 資源利用率提升之道 03：rubik 混部引擎簡(jiǎn)介》。

針對(duì)本文提到的 CPU 優(yōu)先級(jí)的配置，用戶只需要在部署業(yè)務(wù) pod 時(shí)，在 yaml 內(nèi)添加volcano.sh/preemptable的 annotation 標(biāo)識(shí)業(yè)務(wù)屬性，rubik 就會(huì)自動(dòng)設(shè)置 pod 對(duì)應(yīng) cgroup 組的 cpu.qos_level 值。例如，如下為一個(gè) nginx 在線業(yè)務(wù) pod 的 yaml 文件：

# cat nginx-online.yamlapiVersion: v1kind: Podmetadata:  name: nginx-online  annotations:    volcano.sh/preemptable: "false"   # volcano.sh/preemptable為true代表業(yè)務(wù)為離線業(yè)務(wù)，false代表業(yè)務(wù)為在線業(yè)務(wù)，默認(rèn)為falsespec:  containers:  - name: nginx    image: nginx    resources:      limits:        memory: "200Mi"        cpu: "1"      requests:        memory: "200Mi"        cpu: "1"

執(zhí)行kubectl apply -f nginx-online.yaml部署 nginx 業(yè)務(wù)后，進(jìn)入nginx-onlinePod 對(duì)應(yīng)的 cgroup 路徑下，查看cpu.qos_level是否已設(shè)置（在線業(yè)務(wù)為 0，離線業(yè)務(wù)為-1）：

# cat /sys/fs/cgroup/cpu/kubepods/pod59f1cdfa-a0ad-4208-9e95-efbef3519c00/cpu.qos_level0

「總結(jié)」

本文介紹的“CPU 在離線搶占”和“SMT 隔離控制”在在離線混部場(chǎng)景對(duì) CPU 資源進(jìn)行管控，已經(jīng)有比較好的效果了，但還有一些不夠完美的地方，如 LLC/MBA 動(dòng)態(tài)調(diào)整軟件策略不夠精細(xì)，要達(dá)到較好的效果依賴硬件優(yōu)先級(jí)算法，我們可以期待新的鯤鵬服務(wù)器。同時(shí)在公有云場(chǎng)景對(duì)鄰居干擾的消減也是很重要的，openEuler 在這方法也做了一些探索，“潮汐 affinity”技術(shù)取得了不俗的效果，也會(huì)在后續(xù)的文章中與大家見面。下一期將會(huì)分享資源利用率內(nèi)存相關(guān)的技術(shù)。