「概述」

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

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

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

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

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

特性一、CPU 搶占

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

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

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

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

圖 1 離線任務(wù) throttle

特性二、SMT 隔離控制

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

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

方案需要重點解決的問題

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

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

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

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

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

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

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

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

任務(wù)管理

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

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

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

于是，如果想要對任務(wù)進(jìn)行管理，可以在工作節(jié)點上創(chuàng)建離線任務(wù)組，將離線任務(wù)的 pid 寫入到該組的 task 中，再設(shè)置對應(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)行管理

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

針對本文提到的 CPU 優(yōu)先級的配置，用戶只需要在部署業(yè)務(wù) pod 時，在 yaml 內(nèi)添加volcano.sh/preemptable的 annotation 標(biāo)識業(yè)務(wù)屬性，rubik 就會自動設(shè)置 pod 對應(yīng) cgroup 組的 cpu.qos_level 值。例如，如下為一個 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 對應(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 隔離控制”在在離線混部場景對 CPU 資源進(jìn)行管控，已經(jīng)有比較好的效果了，但還有一些不夠完美的地方，如 LLC/MBA 動態(tài)調(diào)整軟件策略不夠精細(xì)，要達(dá)到較好的效果依賴硬件優(yōu)先級算法，我們可以期待新的鯤鵬服務(wù)器。同時在公有云場景對鄰居干擾的消減也是很重要的，openEuler 在這方法也做了一些探索，“潮汐 affinity”技術(shù)取得了不俗的效果，也會在后續(xù)的文章中與大家見面。下一期將會分享資源利用率內(nèi)存相關(guān)的技術(shù)。