當(dāng)前位置：首頁 > 科技 > 軟件

集群 CPU 利用率均值達(dá) 45% ，揭秘小紅書規(guī)模化混部技術(shù)實(shí)踐

來源：責(zé)編：時間：2024-01-03 09:12:24 246觀看

導(dǎo)讀根據(jù) Gartner 預(yù)測數(shù)據(jù)顯示：2024 年全球 IT 支出預(yù)計將達(dá)到 5.1 萬億美元，比 2023 年增長 8 %。然而，該機(jī)構(gòu)的另一項(xiàng)調(diào)查數(shù)據(jù)顯示：全球數(shù)據(jù)中心服務(wù)器平均 CPU 利用率普遍低于 20%，存在巨大的資源浪費(fèi)。據(jù)測算，以數(shù)百萬核 C

根據(jù) Gartner 預(yù)測數(shù)據(jù)顯示：2024 年全球 IT 支出預(yù)計將達(dá)到 5.1 萬億美元，比 2023 年增長 8 %。然而，該機(jī)構(gòu)的另一項(xiàng)調(diào)查數(shù)據(jù)顯示：全球數(shù)據(jù)中心服務(wù)器平均 CPU 利用率普遍低于 20%，存在巨大的資源浪費(fèi)。據(jù)測算，以數(shù)百萬核 CPU 規(guī)模的數(shù)據(jù)中心為例，每提升 1 個百分點(diǎn)的整體資源利用率，每年將節(jié)省數(shù)千萬元的成本。由此可見，提高資源利用率對于降低企業(yè)運(yùn)營成本具有顯著的效果。

早在 2015 年，谷歌就在其經(jīng)典論文《Large-scale cluster management at Google with Borg》中披露了它在資源管理和調(diào)度方面的實(shí)踐經(jīng)驗(yàn)，是最早通過混部技術(shù)來提升資源利用率的公司之一。國內(nèi)多家頭部互聯(lián)網(wǎng)企業(yè)也相繼實(shí)施類似的技術(shù)方案，并取得可觀的資源利用率提升效果。

隨著小紅書業(yè)務(wù)的高速發(fā)展，各類在線、離線業(yè)務(wù)對計算資源的需求日益增長。與此同時，我們觀察到：部分在線集群天均利用率的水位卻維持在較低的水平。造成這一現(xiàn)象的主要原因有以下幾點(diǎn)：

在線服務(wù)資源使用量隨著終端用戶的使用習(xí)慣呈現(xiàn)穩(wěn)定的潮汐現(xiàn)象，夜間 CPU 利用率極低，從而導(dǎo)致整個集群的均值 CPU 利用率降低。
業(yè)務(wù)保有大量的獨(dú)占資源池，資源池割裂產(chǎn)生大量的資源碎片，進(jìn)而降低 CPU 的利用率。
出于穩(wěn)定性考慮，業(yè)務(wù)傾向于過量儲備資源，進(jìn)一步降低 CPU 的利用率。

基于以上背景，為了幫助業(yè)務(wù)降低資源使用成本，小紅書容器團(tuán)隊(duì)從 2022 年開始規(guī)模化落地混部技術(shù)，提升集群 CPU 利用率。截止目前，混部集群 CPU 利用率均值可達(dá) 45% 以上，為業(yè)務(wù)提供數(shù)百萬核時的算力成本優(yōu)化。

一、技術(shù)演進(jìn)

小紅書混部技術(shù)演進(jìn)分為以下四個階段（如圖所示）：

圖片

階段一：閑置資源再利用

在早期，小紅書的集群資源管理相對粗放，集群中存在大量業(yè)務(wù)獨(dú)占的資源池。由于資源碎片化等因素，各個集群中存在許多低分配率的低效節(jié)點(diǎn)，導(dǎo)致大量資源浪費(fèi)。同時，基于 Kubernetes（K8s）發(fā)布的轉(zhuǎn)碼類近線/離線場景，在全天時段均存在大量計算資源需求。基于以上背景，小紅書容器平臺通過技術(shù)手段將集群中的閑置資源進(jìn)行收集，并將其分配給轉(zhuǎn)碼類業(yè)務(wù)場景使用。

整體架構(gòu)上，離線業(yè)務(wù)發(fā)布入口統(tǒng)一收斂在在一個集群，我們稱之為元數(shù)據(jù)集群，目的是為業(yè)務(wù)屏蔽底層多物理 K8s 集群。通過 Virtual-Kubelet 連接元數(shù)據(jù)集群與物理集群，將閑置資源匯聚到元數(shù)據(jù)集群，在元數(shù)據(jù)集群中調(diào)度分發(fā)轉(zhuǎn)碼類任務(wù)到底層物理集群。

策略方面，二次調(diào)度器負(fù)責(zé)巡檢集群中的所有節(jié)點(diǎn)，識別出低效節(jié)點(diǎn)并進(jìn)行標(biāo)記；隨后 Virtual-Kubelet 獲取物理集群中的低效節(jié)點(diǎn)可用資源作為集群閑置資源，再次分配給離線轉(zhuǎn)碼場景。同時，二次調(diào)度器確保一旦在線服務(wù)有資源需求，將會立刻驅(qū)逐離線 Pod 并歸還資源。通過此舉，我們能夠提高集群資源的利用效率，減少資源浪費(fèi)，并滿足轉(zhuǎn)碼類場景對計算資源的需求。

圖片

階段二：整機(jī)騰挪分時復(fù)用

搜推廣等業(yè)務(wù)的獨(dú)占資源池，存在明顯的 CPU 利用率潮汐現(xiàn)象，尤其夜間利用率極低。通常情況下，資源池中的單個節(jié)點(diǎn)往往也只部署一個大規(guī)格業(yè)務(wù) Pod。基于這種情況，平臺通過彈性能力（HPA），在凌晨業(yè)務(wù)低峰期按比例對在線業(yè)務(wù)進(jìn)行縮容，釋放出整機(jī)資源，并將轉(zhuǎn)碼、訓(xùn)練等離線 Pod 在該時段運(yùn)行起來，實(shí)現(xiàn)資源優(yōu)化，起到利用率“填谷”的效果。

在具體實(shí)施過程中，我們需要確保在線服務(wù)能夠在規(guī)定的時間內(nèi)全部被拉起。為此，我們采取以下策略：實(shí)現(xiàn)離線服務(wù)的提前退場，并通過調(diào)度器的搶占機(jī)制進(jìn)行兜底，確保在線服務(wù)在業(yè)務(wù)高峰期來臨之前能被全量且及時地重新啟動。

這一階段能最大限度地利用資源，使得離線服務(wù)在低峰期得到有效運(yùn)行，同時保證在線服務(wù)在業(yè)務(wù)高峰期能夠快速恢復(fù)運(yùn)行。

圖片

階段三：常態(tài)混部

為了降低資源碎片率和業(yè)務(wù)資源持有成本，平臺持續(xù)推進(jìn)業(yè)務(wù)的大規(guī)模合池，將業(yè)務(wù)從獨(dú)占資源池遷移到平臺托管的公共混部池。通過合池、資源超賣等技術(shù)手段，我們有效提升了 CPU 分配率，但依舊無法解決合并后的資源池夜間利用率較低等問題。另外，在合池后的復(fù)雜混部場景下，整機(jī)騰挪、分時混部離線的調(diào)度策略很難再繼續(xù)實(shí)施。平臺需要建設(shè)更為細(xì)粒度的資源管理與調(diào)度能力，來實(shí)現(xiàn)均值利用率提升的目標(biāo)，具體包含以下幾點(diǎn)：

1. 調(diào)度側(cè)

通過動態(tài)超賣技術(shù)獲取可用于二次分配給離線服務(wù)的可用資源量，并抽象出離線資源視圖，使得 K8s 調(diào)度器感知到這些離線資源。調(diào)度器調(diào)度離線負(fù)載到對應(yīng)節(jié)點(diǎn)上，實(shí)現(xiàn)離線服務(wù)對節(jié)點(diǎn)利用率的“填谷”效果。
通過負(fù)載調(diào)度，盡可能避免在線服務(wù)被調(diào)度到高負(fù)載機(jī)器上，讓集群中節(jié)點(diǎn)負(fù)載更加均衡。
通過二次調(diào)度，驅(qū)逐負(fù)載熱點(diǎn)機(jī)器上的高利用率服務(wù)，使得集群負(fù)載保持動態(tài)均衡狀態(tài)。

2. 單機(jī)側(cè)

支持 QoS（Quality of Service）保障策略，根據(jù)服務(wù)的 QoS 等級提供差異化的運(yùn)行時資源保障能力。
支持干擾檢測、離線驅(qū)逐等能力，當(dāng)離線服務(wù)對在線敏感服務(wù)產(chǎn)生干擾時，第一時間驅(qū)逐離線服務(wù)。

通過以上技術(shù)手段，我們能夠有效地保障服務(wù)混合部署時的穩(wěn)定性，從而實(shí)現(xiàn)在線和離線工作負(fù)載在節(jié)點(diǎn)上的常態(tài)混合運(yùn)行，實(shí)現(xiàn)利用率“填谷”效果的最大化。

圖片

階段四：統(tǒng)一調(diào)度

隨著常態(tài)混部和大規(guī)模資源合池的持續(xù)推進(jìn)，小紅書云原生資源調(diào)度將會面臨以下挑戰(zhàn)：

1. 各類業(yè)務(wù)場景對資源調(diào)度存在復(fù)雜且各異的功能和性能需求

大數(shù)據(jù)、AI 場景下：排隊(duì)調(diào)度、批量調(diào)度（All-or-Nothing）、高吞吐量調(diào)度等需求。
在線敏感服務(wù)場景下：資源調(diào)度成功率保障性需求、服務(wù)運(yùn)行時質(zhì)量保障性需求。

2. GPU 等異構(gòu)資源調(diào)度需求

支持 GPU 共享調(diào)度、bin packing等調(diào)度能力，以提升 GPU 利用率及 GPU 機(jī)器上的 CPU 利用率。
支持 GPU 拓?fù)涓兄⒂H和性調(diào)度等調(diào)度能力，通過優(yōu)化 GPU 間的通信效率，大幅提升大規(guī)模訓(xùn)練效率。

基于以上背景，我們提出面向混合云架構(gòu)的統(tǒng)一調(diào)度方案。該方案基于統(tǒng)一資源池，通過統(tǒng)一調(diào)度能力來管理異構(gòu)計算資源，并支持各類業(yè)務(wù)形態(tài)的工作負(fù)載調(diào)度能力。通過站在全局視角，將工作負(fù)載調(diào)度到最合適的節(jié)點(diǎn)，讓業(yè)務(wù)跑得更快更穩(wěn)定，并降低全局資源使用成本。涉及到的關(guān)鍵技術(shù)點(diǎn)如下：

1. 在離線統(tǒng)一調(diào)度

提供以 K8s 為底座的統(tǒng)一調(diào)度能力，支持包含在線敏感型服務(wù)、大數(shù)據(jù)/ AI 任務(wù)型工作負(fù)載在內(nèi)的統(tǒng)一資源調(diào)度。

2. QoS 感知調(diào)度

基于服務(wù)畫像，結(jié)合系統(tǒng)指標(biāo)識別干擾源，并刻畫節(jié)點(diǎn)資源質(zhì)量。通過綜合調(diào)度、重調(diào)度和單機(jī)調(diào)度等不同維度的調(diào)度能力，降低業(yè)務(wù)間混部造成的干擾，從而提升在線服務(wù)的運(yùn)行質(zhì)量。

3. GPU 調(diào)度

支持 GPU Share、bin packing、多 GPU 卡之間的親和性調(diào)度等調(diào)度能力，以提高 GPU 資源的利用效率。

4. 資源售賣模型

根據(jù)資源質(zhì)量、資源供應(yīng)形態(tài)（如常態(tài)化供應(yīng)資源、分時潮汐資源、Spot 資源）和資源套餐規(guī)格等多個維度，定義差異化資源售賣模型，降低資源綜合使用成本。

5. 資源配額

支持資源配額管理能力，包括分時配額、彈性配額和層級結(jié)構(gòu)管理等功能，避免多租戶之間的資源爭搶，提升資源使用效率。

二、架構(gòu)設(shè)計與實(shí)現(xiàn)

小紅書容器統(tǒng)一資源調(diào)度系統(tǒng) Tusker (The Unified Scheduling system base on Kubernetes for Efficiency and Reliability) 架構(gòu)設(shè)計如圖所示：

圖片

小紅書的各類業(yè)務(wù)場景通過多個發(fā)布平臺和任務(wù)平臺提交，并通過上層負(fù)載編排能力，以 Pod 形式下發(fā)到統(tǒng)一調(diào)度系統(tǒng)。統(tǒng)一調(diào)度系統(tǒng)基于不同的調(diào)度需求，為在線服務(wù)提供強(qiáng)保障的資源交付能力、差異化的 QoS 保障能力，同時為離線服務(wù)提供最小資源需求的保障能力和極致的彈性能力。

在調(diào)度側(cè)，離線調(diào)度采用 Coscheduling 技術(shù)；二次調(diào)度處理資源熱點(diǎn)問題，包括熱點(diǎn)驅(qū)逐和碎片整理；負(fù)載調(diào)度基于 CPU 水位進(jìn)行調(diào)度，以實(shí)現(xiàn)更好地資源利用；資源視圖用于資源走查和模擬調(diào)度。

在單機(jī)側(cè)，通過壓制策略如 BVT（Borrowed Virtual Time）進(jìn)行性能控制和資源限制，并進(jìn)行內(nèi)存驅(qū)逐操作；QoS 保障方面，采用綁核和超線程干擾抑制等技術(shù)來實(shí)現(xiàn)資源的差異化保障；計算和上報可用的 Batch 資源信息；來自 Kernel 的指標(biāo)采集包括 PSI（Pressure Stall Information）、調(diào)度信息等；干擾檢測基于 CPI（Cycles Per lnstruction）、PSI（Pressure Stall Information）和業(yè)務(wù)指標(biāo)等，用于檢測和處理干擾情況。

2.1 離線調(diào)度資源視圖

離線服務(wù)資源調(diào)度的基本原理是基于在線服務(wù)負(fù)載感知能力的動態(tài)超賣，具體實(shí)現(xiàn)是將節(jié)點(diǎn)空閑資源二次分配給離線業(yè)務(wù)：

圖片

其中離線可用資源為節(jié)點(diǎn)上的空閑資源（包含未分配資源和已分配未使用資源之和），扣除安全預(yù)留資源之后的剩余資源，離線可用資源計算公式如下：

離線可用資源 = 整機(jī)資源 – 預(yù)留資源 – 在線服務(wù)實(shí)際使用量

將計算出的離線可用資源量按照時間分布后如圖所示（圖中綠色部分）：

圖片

實(shí)際落地過程中，為了避免離線可用資源隨在線服務(wù)資源使用波動而大幅波動，從而影響離線資源質(zhì)量和離線服務(wù)運(yùn)行穩(wěn)定性，可以通過資源畫像對上述公式中的在線服務(wù)實(shí)際使用量數(shù)據(jù)進(jìn)一步處理，去除數(shù)據(jù)噪點(diǎn)，最終計算出一個相對穩(wěn)定的離線可用資源量（圖中綠色部分），如圖所示：

圖片

2.2 混部 QoS 保障策略

2.2.1 QoS 分級

按照業(yè)務(wù)對于服務(wù)質(zhì)量（QoS: Quality of Service）的需求，小紅書的業(yè)務(wù)類型可以簡單劃分為三個 QoS 級別，如下表所示：

QoS 等級	說明	業(yè)務(wù)場景
Latency-Sensitive	最高 QoS 保障等級，延遲極為敏感服務(wù)	搜推廣延遲極為敏感場景
Mid	默認(rèn) QoS 保障等級，容忍部分干擾延遲	網(wǎng)關(guān)、Java 微服務(wù)
Batch	最低 QoS 保障等級，延遲不敏感，資源隨時可能被搶	轉(zhuǎn)碼、Spark、Flink、訓(xùn)練等計算場景

2.2.2 QoS 保障

根據(jù)服務(wù)的 QoS 需求，節(jié)點(diǎn)側(cè)可以采取 Pod 粒度的分級資源保障，以實(shí)現(xiàn)不同資源維度的差異化 QoS 保障策略，具體的保障參數(shù)如下：

資源	特性	Latency-Sensitive	Mid	Batch
CPU	CPU Burst	enable	enable	disable
	調(diào)度優(yōu)先級	最高	默認(rèn)	低
	綁核	share （默認(rèn)）	share（默認(rèn)）	reclaimed
	NUMA	強(qiáng)保證	prefer（默認(rèn)）	none
	L3 Cache	100%	100%（默認(rèn)）	30% （默認(rèn)）
	內(nèi)存帶寬	100%	100%（默認(rèn)）	30% （默認(rèn)）
內(nèi)存	OOM 優(yōu)先級	最低	默認(rèn)	最高
內(nèi)存	內(nèi)存回收水線	調(diào)高	默認(rèn)	調(diào)低

在 CPU 核編排層面，我們針對不同的需求場景，設(shè)置了三種不同的綁核類型，并設(shè)計了一套精細(xì)化 CPU 核編排策略，分配示意圖如下：

圖片

三種綁核類型分別為：

Exclusive

特點(diǎn)：綁定 cpuset 調(diào)度域、CCD 感知、NUMA 綁定、獨(dú)占排他
場景：適用于對延遲極為敏感的搜推廣大規(guī)格服務(wù)

Share（推薦）

特點(diǎn)：綁定 cpuset 調(diào)度域、CCD 感知、NUMA（可選）綁定、Share/Exlusive 排他、可與 None 類型業(yè)務(wù)共享
場景：適用于容忍部分干擾的 Java 微服務(wù)、應(yīng)用網(wǎng)關(guān)、Web服務(wù)等

Reclaimed

特點(diǎn)：無 cpuset 綁定、可能與非 exlusive 綁核模式的業(yè)務(wù)共享核，核的分配完全由內(nèi)核控制，CPU 資源并非百分之百能夠滿足需求
場景：適用于 Batch 類離線服務(wù)，部分對延遲無要求的計算服務(wù)

2.2.3 離線驅(qū)逐

在極端場景下，如整機(jī)內(nèi)存使用率較高、有觸發(fā) OOM 風(fēng)險，或者離線業(yè)務(wù) CPU 長期得不到滿足時，可以采取離線驅(qū)逐策略。單機(jī)側(cè)支持按照離線服務(wù)內(nèi)部定義的優(yōu)先級配置、資源用量和運(yùn)行時長等多維度綜合算分排序后，按序驅(qū)逐離線服務(wù)，以達(dá)到最優(yōu)的資源利用效果。

2.3 離線業(yè)務(wù)場景舉例

小紅書作為一個擁有數(shù)億用戶的內(nèi)容社區(qū)，其離線業(yè)務(wù)場景豐富多樣，其中包含大量視頻類和圖片類轉(zhuǎn)碼場景、搜推、CV/NLP 算法推理訓(xùn)練、算法特征生產(chǎn)以及數(shù)倉查詢等離線場景。具體而言，包含以下業(yè)務(wù)類型：

近離線轉(zhuǎn)碼場景（已容器化）
Flink 流式/批式計算（已容器化）
Spark 批式計算（未容器化、On YARN）
CV/NLP 算法回掃場景（已容器化）
訓(xùn)練場景（已容器化）

通過基于 K8s 的在離線統(tǒng)一調(diào)度能力，將這些離線業(yè)務(wù)與在線服務(wù)混合部署在統(tǒng)一資源池中。不僅能為在線服務(wù)提供差異化的資源質(zhì)量保障，亦能為離線服務(wù)提供海量的低成本算力，以實(shí)現(xiàn)資源效能的提升。

圖片

2.3.1 K8s 與 YARN 混部方案

在小紅書商業(yè)化、社區(qū)搜索等業(yè)務(wù)中存在大量的算法類 Spark 任務(wù)，由于離線集群資源緊張，任務(wù)無法及時處理，導(dǎo)致任務(wù)堆積。同時，在線集群在業(yè)務(wù)低峰時段資源使用率較低。另外，相當(dāng)大比例的 Spark 任務(wù)資源調(diào)度仍運(yùn)行在 YARN 調(diào)度器上。基于此背景，為了快速降低業(yè)務(wù)遷移成本，在方案選型方面，我們選擇與 Kooridinator 社區(qū)合作，采用 YARN on K8s 混部方案來快速落地 Spark 離線場景混部，具體方案如圖所示：

圖片

在線和離線工作負(fù)載在容器化環(huán)境下通過 K8s 鏈路發(fā)布到在線集群內(nèi)。Spark 作業(yè)通過 YARN ResourceManager 調(diào)度到具體節(jié)點(diǎn)，并由節(jié)點(diǎn)上的 NodeManager 組件拉起。NodeManager 以容器的形式部署在在線 K8s 集群中，實(shí)現(xiàn)資源的有效管理。除此之外，還涉及到以下組件：

1. 調(diào)度側(cè)

Koord-Yarn-Operator：支持 K8s 與 YARN 調(diào)度器資源視圖的雙向同步，確保資源信息的共享和一致性。

2. 節(jié)點(diǎn)側(cè)

Copilot：作為 NodeManager 的操作代理，提供 YARN Task 的管控接口。
Tusker-agent/koordlet：負(fù)責(zé)離線資源的上報、節(jié)點(diǎn)上離線 Pod/Task 管理，并處理沖突解決、驅(qū)逐、壓制策略等功能。

多調(diào)度器資源同步

K8s 調(diào)度器與 YARN 調(diào)度器之間原本獨(dú)立且相互不感知，為了共享分配節(jié)點(diǎn)上的總可用離線資源，需要通過 Koord-Yarn-Operator 組件來做兩個調(diào)度器之間的資源雙向同步和協(xié)調(diào)，并實(shí)現(xiàn)兩個同步鏈路：

1. K8s ->YARN 調(diào)度器資源同步鏈路，負(fù)責(zé)同步 YARN 視角離線資源總量，其中 YARN 離線資源總量計算如下：

YARN離線資源總量 = 離線總可用量 – K8s 側(cè)節(jié)點(diǎn)已分配

2. YARN->K8s 調(diào)度器資源同步鏈路，負(fù)責(zé)同步已分配的 YARN 資源量，其中 K8s 離線資源總量計算如下：

K8s 離線資源總量 = 離線總可用量 – YARN 側(cè)節(jié)點(diǎn)已分配

基于各自節(jié)點(diǎn)離線資源視圖，兩個調(diào)度器分別作出調(diào)度決策，將離線 Pod 與 YARN Task 調(diào)度到適當(dāng)?shù)墓?jié)點(diǎn)上。由于同步過程不適合加鎖，可能會出現(xiàn)資源被過量分配的問題：

圖片

具體解決措施是在單機(jī)側(cè)增加了仲裁邏輯。當(dāng)節(jié)點(diǎn)已分配的離線服務(wù)資源量長期超過節(jié)點(diǎn)可用離線資源，且離線使用率持續(xù)較高時，存在離線服務(wù)無法獲得資源而被餓死的風(fēng)險。單機(jī)側(cè)會根據(jù)離線服務(wù)的優(yōu)先級、資源占用量和運(yùn)行時長等因素綜合算分，并按序驅(qū)逐。

三、落地收益

截止目前，小紅書混部能力覆蓋數(shù)十萬臺機(jī)器規(guī)模，覆蓋算力規(guī)模數(shù)百萬核，支持?jǐn)?shù)萬規(guī)模在線、離線場景服務(wù)的資源調(diào)度。通過大規(guī)模容器混部的持續(xù)推進(jìn)，小紅書在資源成本效能等方面都取得了顯著收益，具體包含以下兩方面：

CPU 利用率

在保證在線服務(wù)服務(wù)質(zhì)量的前提下，在線混部集群天均 CPU 利用率提升至 45% 以上，部分集群天均 CPU 利用率可穩(wěn)定提升至 55%。
通過在離線混部等技術(shù)手段，在線集群 CPU 利用率提升 8%-15% 不等，部分存儲集群利用率提升可達(dá) 20% 以上。

資源成本

在保證離線業(yè)務(wù)穩(wěn)定性的前提下，為小紅書各類離線場景提供數(shù)百萬核時的低成本算力。
混部集群 CPU 分配率提升至 125% 以上，相較于獨(dú)占資源池，資源碎片率明顯下降。

四、總結(jié)與展望

在小紅書近一年多的混部技術(shù)探索中，我們在資源效能提升方面積累了較為豐富的落地經(jīng)驗(yàn)，并取得了不錯的收益。隨著公司業(yè)務(wù)規(guī)模逐步增長，場景愈發(fā)復(fù)雜，我們將會面臨諸多新的技術(shù)挑戰(zhàn)。展望未來，我們的目標(biāo)是建設(shè)面向混合云架構(gòu)的統(tǒng)一資源調(diào)度能力，具體工作將圍繞以下三方面展開：

混合工作負(fù)載調(diào)度能力支持：為了滿足小紅書所有業(yè)務(wù)場景的資源調(diào)度功能、性能需求，重點(diǎn)發(fā)展任務(wù)型工作（包括大數(shù)據(jù)、AI等）的負(fù)載調(diào)度能力建設(shè)。
資源效能進(jìn)一步提升：面向混合云架構(gòu)，我們將推進(jìn)更大規(guī)模的資源合池，推動 Quota 化資源交付。通過采用更先進(jìn)的彈性、混部、超賣等技術(shù)手段，進(jìn)一步提升集群資源利用率，實(shí)現(xiàn)資源成本的大幅度下降。
更高服務(wù)質(zhì)量保障能力：在更具挑戰(zhàn)性的 CPU 利用率目標(biāo)下，我們將建設(shè) QoS 感知調(diào)度能力、干擾檢測能力，并依托安全容器等技術(shù)手段，解決深水區(qū)混部中可能遇到的各類干擾問題。

作者簡介

桑鐸（宋澤輝）：基礎(chǔ)技術(shù)部/云原生平臺

小紅書資源調(diào)度負(fù)責(zé)人，在容器資源調(diào)度、混部部署、資源隔離等方面有豐富的實(shí)踐經(jīng)驗(yàn)，目前主要負(fù)責(zé)小紅書大規(guī)模容器資源調(diào)度、在離線混部等方向的技術(shù)研發(fā)工作。

黃瀨（索增增）：基礎(chǔ)技術(shù)部/云原生平臺

小紅書資源調(diào)度資深研發(fā)工程師，主要負(fù)責(zé)資源調(diào)度、工作負(fù)載編排相關(guān)的研發(fā)工作。

灰仔（葉楊婕）：基礎(chǔ)技術(shù)部/云原生平臺

小紅書資源調(diào)度研發(fā)工程師，主要負(fù)責(zé)在離線混部方向研發(fā)工作。

特別感謝：小紅書音視頻架構(gòu)組、數(shù)據(jù)引擎組、交易算法組所有業(yè)務(wù)方同學(xué)。

本文鏈接：http://www.www897cc.com/showinfo-26-56572-0.html集群 CPU 利用率均值達(dá) 45% ，揭秘小紅書規(guī)模化混部技術(shù)實(shí)踐

聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com

上一篇：如何提高 Java 代碼的可重用性

下一篇： Spring Boot中集成各種日志框架Logback、Log4j2和Java Util Logging

標(biāo)簽：

熱門焦點(diǎn)

影音體驗(yàn)是真的強(qiáng) 簡單聊聊iQOO Pad

大公司的好處就是產(chǎn)品線豐富，非常細(xì)分化的東西也能給你做出來，例如早先我們看到了新的vivo Pad2，之后我們又在iQOO Neo8 Pro的發(fā)布會上看到了iQOO的首款平板產(chǎn)品iQOO Pad。雖
7月安卓手機(jī)好評榜：三星S23Ultra好評率第一

性能榜和性價比榜之后，我們來看最后的安卓手機(jī)好評榜，數(shù)據(jù)來源安兔兔評測，收集時間2023年7月1日至7月31日，僅限國內(nèi)市場。第一名：三星Galaxy S23 Ultra好評率：95.71%在即將迎來新
服務(wù)存儲設(shè)計模式：Cache-Aside模式

Cache-Aside模式一種常用的緩存方式，通常是把數(shù)據(jù)從主存儲加載到KV緩存中，加速后續(xù)的訪問。在存在重復(fù)度的場景，Cache-Aside可以提升服務(wù)性能，降低底層存儲的壓力，缺點(diǎn)是緩存和底
一篇聊聊Go錯誤封裝機(jī)制

%w 是用于錯誤包裝（Error Wrapping）的格式化動詞。它是用于 fmt.Errorf 和 fmt.Sprintf 函數(shù)中的一個特殊格式化動詞，用于將一個錯誤（或其他可打印的值）包裝在一個新的錯誤中。使
如何使用JavaScript創(chuàng)建一只圖像放大鏡？

譯者 | 布加迪審校 | 重樓如果您曾經(jīng)瀏覽過購物網(wǎng)站，可能遇到過圖像放大功能。它可以讓您放大圖像的特定區(qū)域，以便瀏覽。結(jié)合這個小小的重要功能可以大大改善您網(wǎng)站的用戶體驗(yàn)
本地生活這塊肥肉，拼多多也想吃一口

出品/壹覽商業(yè) 作者/李彥編輯/木魚拼多多也看上本地生活這塊蛋糕了。近期，拼多多在App首頁“充值中心”入口上線了本機(jī)生活界面。壹覽商業(yè)發(fā)現(xiàn)，該界面目前主要
10天營收超1億美元，《星鐵》比《原神》差在哪？

來源：伯虎財經(jīng)作者：陳平安即便你沒玩過《原神》，你一定聽說過的它的大名。恨它的人把《原神》開服那天稱作是中國游戲史上最黑暗的一天，有粉絲因?yàn)樗髂嵩赑S平臺上線《原神》，怒而
網(wǎng)紅炒股不為了賺錢，那就是耍流氓！

來源：首席商業(yè)評論6月26日高調(diào)宣布入市，網(wǎng)絡(luò)名嘴大v胡錫進(jìn)居然進(jìn)軍了股市。在一次財經(jīng)媒體峰會上，幾個財經(jīng)圈媒體大佬就“胡錫進(jìn)炒股是否知道認(rèn)真報道”展開討論。有
與兆芯合作聯(lián)想推出全新旗艦版筆記本電腦開天N7系列

聯(lián)想與兆芯合作推出全新聯(lián)想旗艦版筆記本電腦開天 N7系列。這個系列采用兆芯KX-6640MA處理器平臺，KX-6640MA 處理器是采用了陸家嘴架構(gòu)，16nm 工藝，4 核 4 線

日韩成人免费在线_国产成人一二_精品国产免费人成电影在线观..._日本一区二区三区久久久久久久久不

集群 CPU 利用率均值達(dá) 45% ，揭秘小紅書規(guī)模化混部技術(shù)實(shí)踐

一、技術(shù)演進(jìn)

階段一：閑置資源再利用

階段二：整機(jī)騰挪分時復(fù)用

階段三：常態(tài)混部

階段四：統(tǒng)一調(diào)度

二、架構(gòu)設(shè)計與實(shí)現(xiàn)

2.1 離線調(diào)度資源視圖

2.2 混部 QoS 保障策略

2.2.1 QoS 分級

2.2.2 QoS 保障

2.2.3 離線驅(qū)逐

2.3 離線業(yè)務(wù)場景舉例

2.3.1 K8s 與 YARN 混部方案

三、落地收益

四、總結(jié)與展望

作者簡介

影音體驗(yàn)是真的強(qiáng) 簡單聊聊iQOO Pad

7月安卓手機(jī)好評榜：三星S23Ultra好評率第一

服務(wù)存儲設(shè)計模式：Cache-Aside模式

一篇聊聊Go錯誤封裝機(jī)制

如何使用JavaScript創(chuàng)建一只圖像放大鏡？

本地生活這塊肥肉，拼多多也想吃一口

10天營收超1億美元，《星鐵》比《原神》差在哪？

網(wǎng)紅炒股不為了賺錢，那就是耍流氓！

與兆芯合作聯(lián)想推出全新旗艦版筆記本電腦開天N7系列

最新推薦

猜你喜歡

熱門推薦

相關(guān)資訊