前文[1]介紹了資源使用率提升這個課題的産生背景、形成原因、解決思路，以及在 openEuler 上所建構的資源使用率整體解決方案和技術演進思路。
本篇我們針對容器在離線場景下的典型應用類型（ CPU 敏感型、記憶體敏感型、網絡 IO 敏感型 ），并在搭載了 openEuler 混合部署 QoS 方案的 x86 環境上展開了專項的應用場景測試。
案例 1：CPU 排程敏感型應用
針對 CPU 排程敏感型應用場景，我們選擇了 CloudSuite[2]的兩個測試套件作為混合部署的在離線業務進行混部：
- 線上業務選用「Web Serving」 測試套[3]：模拟使用者向社交網絡伺服器發送不同請求的場景，服務端基于社交網絡引擎（Elgg）實作，用戶端根據 Faban 工作負載生成器實作。業務性能度量名額為平均每秒操作數、響應時延等。
- 離線業務選用「In-Memory Analytics」 測試套[4]：通過 Apache Spark 在記憶體中運作協作過濾算法訓練使用者電影評級模型，生成測試使用者推薦電影清單。業務性能度量名額為計算電影推薦的時間（以秒為機關）。
從應用特征上而言，Web Serving 為 CPU 敏感型應用，且具有實時性，對響應延遲敏感度高，符合線上業務的特征，In-Memory Analytics 為 CPU 密集型業務，消耗大量的計算資源，符合離線業務的特征，将此二者混合部署能夠有效利用 Web Serving 空閑時的 CPU 資源，實作資源使用率的提升，但如果隻是簡單地混合部署，CPU 密集的離線業務必然會對線上業務産生極大的幹擾，采用混部 QoS 特性實作線上業務的 CPU 搶占，能夠有效保障線上業務的性能。
測試設計上，始終關注線上業務的性能資料，然後分别測試三組資料：
- 線上業務單獨運作時，線上業務 Web Serving 的性能資料
- 在離線業務混部、無混部 QoS 特性幹預下，線上業務 Web Serving 的性能資料
- 在離線業務混部、有混部 QoS 特性幹預下，線上業務 Web Serving 的性能資料
通過将三組的測試資料放到一起，獲得如下兩個曲線圖：
從上面的曲線資料圖可見，在 2 小時的測試周期裡， 沒有開啟混部 QoS 特性的測試 2，線上業務受到了明顯的幹擾，Web Serving 對 BrowsetoElgg 以及 Register 請求的平均響應時間均延長到了 3 倍左右，可見線上業務在受到離線業務幹擾後性能下降了 3 倍；而開啟了混部 QoS 特性的測試 3，線上業務的性能基本能夠與僅運作線上業務的測試 1 持平。
以上測試結果表明，當業務之間發生 CPU 争搶時，混部 QoS 方案加持下的線上業務優先得到了關鍵的 CPU 資源。這其中，openEuler 的 CPU 絕對搶占技術發揮了巨大的作用。
案例 2：CPU 限流敏感型應用
通常，使用者在 Kubernetes 叢集中部署業務時需要限制容器可使用 CPU 數量。然而，固定的資源難以滿足 CPU 限流敏感型業務（即對短時突發流量敏感的應用）的運作需求。例如：
- 單個應用執行個體 CPU 規格較小 ，使用率較低，有規律突發增長
- 應用長期平穩運作，運作過程中突發 CPU 使用飙升
- 應用總體使用率較低， 但啟動時使用率較高
這幾類場景，相比于案例 1 中所提到的 CPU 排程敏感型，我們将這類應用分類為 CPU 限流敏感型。
為友善測試，我們仿照上述三類短時突發流量業務，模拟了一個長期平穩運作但運作過程中 CPU 會規律性進行突發增長的測試業務，該業務：
- 通過 Stress 工具來擔任線上業務，模拟業務流量短時沖高的場景。在平穩運作時僅占用 1 個 CPU ，每 30 秒規律突發時長為 1ms 的高峰流量，在高峰時期會占用 3 個 CPU
- 将該線上業務部署于 Kubernetes 叢集，并限制該業務最大可用 CPU 數為 2 個 CPU
在測試時，首先開啟 openEuler 的混部 QoS 特性，運作以上測試用例，在測試過程中通過觀察壓制（throttled）次數來觀察容器在應對突發流量時的運作情況。
下圖是測試過程中的應用運作情況。上半部展示容器壓制次數，下半部展示容器運作過程的 CPU 變化情況。其中，在時刻 1~4 ，業務容器會産生突發流量，此時容器的 CPU 使用會從 1 核增加至 3 核。可以看到，随着 openEuler 的混部 QoS 特性主動調整受壓制容器的 CPU 配額值，容器受壓制情況逐漸緩解直至容器不再受到壓制。
由上可見，針對 CPU 限流敏感型應用，openEuler 的混部 QoS 同樣可以對它進行有效的控制。在此過程中，使用了我們所設計的 quotaTurbo 特性。該特性的整體思路是在業務運作過程中，持續監控容器的壓制（ throttled ）狀态，并依據目前 CPU 負載對容器所使用的 CPU 時間片進行分級調整。在保障整機負載水位安全穩定及不影響其他業務的前提下，按需動态調整業務容器 CPU 限額，實作業務 CPU 動态調整、降低了業務的節流率，進而提高業務的整體運作性能。
案例 3：記憶體敏感型應用
前面介紹了兩個 CPU 敏感型應用的例子，接下來我們來看下記憶體敏感型應用在容器在離線混部時會碰到的問題：假設容器在離線混部時，參與混部的離線業務是記憶體消耗型，其占用了過多的記憶體，導緻線上業務在需要的時候申請不到記憶體，進而線上業務的 QoS 下降。
在這種場景下，從技術層面我們需要壓制離線應用的記憶體使用量并及時釋放離線應用所使用的記憶體。是以，我們在 openEuler 的混部 QoS 方案上開發了基于 cgroup 級的記憶體管理快壓制慢恢複方案（FSSR）。
下面，我們通過一個測試用例來驗證 FSSR 方案的效果。我們通過以下這個測試模型進行使用者模拟測試 ：
在本測試裡，圖上各黃色辨別的程序分别擔任以下角色：
- 線上業務（nginx）：因其對時延敏感，擔任線上業務。測試時下載下傳使用者指定的檔案并連續進行傳輸
- 離線業務（stress）：對時延不敏感，但會大量使用記憶體，擔任離線業務。測試時讓其同時進行記憶體和磁盤寫、占用一定數量的匿名記憶體和 page cache
- 用戶端（siege）：由其模拟使用者行為，對線上業務 nginx 發送 HTTP 請求
在測試時，重點觀測點是線上業務的 QoS（即業務的下載下傳耗時），并設計三個測試用例：
- 在離線業務混部，不開啟混部 QoS 的 FSSR 特性
- 在離線業務混部，開啟混部 QoS 的 FSSR 特性
- 僅運作線上業務
在測試完成後，我們獲得如下曲線圖：
能夠看到：
- 如左半圖所示，随着測試時連續下載下傳次數的增加，線上業務的 QoS（下載下傳耗時）開始下降。相比于沒有開啟 FSSR 政策的測試 1，在開啟了 FSSR 政策的測試 2 裡，線上業務的 QoS 得到了顯著的提升。這意味着，當請求下載下傳次數增加，開啟 FSSR 政策時，線上業務的記憶體上限會随着使用量增大而增大，page cache 中會緩存大量已經讀取的檔案，進而減少了磁盤讀寫的次數，保障了線上業務的 QoS
- 如右半圖所示，當開啟 FSSR 政策時（測試 2 ），線上業務的 QoS 能夠與僅運作線上業務（測試 3 ）的記憶體使用量相近。這意味着線上應用會盡可能的利用記憶體的資源，進而在和離線應用競争時能夠處于競争優勢地位
以上測試表明，通過使用動态調整線上業務和離線業務記憶體配置設定的 FSSR 政策，能夠優先保障線上業務的記憶體使用，提升線上業務在在離線混部時的 QoS。
案例 4：網絡 IO 敏感型應用
最後，我們一起來分析下網絡 IO 敏感型應用的場景。當在離線業務混部時，如離線業務某段時間網絡 IO 需求增高，在離線業務産生網絡資源的争搶。此時，線上業務如果無法及時獲得關鍵的網絡資源，就會導緻 QoS 的下降。針對這種場景，我們 openEuler 的混部 QoS 方案開發了容器 POD 帶寬管理特性。
同樣的，我們設計了一個測試用例來驗證該特性的效果。為了便于觀察網絡帶寬的變化，本次測試的線上業務和離線業務均采用了 iperf3[5] 來模拟業務程序。網絡拓撲模型如下 ：
測試步驟如下：
- 在 Node1 上，
- 通過 rubik 開啟 Pod 帶寬管理特性，設定 node 上的離線業務的總體帶寬和線上業務的限流水位
- 給在離線業務容器所在的 cgroup 設定不同的 qos_level，進行在離線業務的辨別
- 在 Node2 上，啟動 iperf3 的用戶端工具給在離線業務發送請求，讓在離線業務按需發起網絡流量。同時設定 4 個時間點：
- 在測試剛開始時，線上業務盡可能的占據網絡帶寬，而離線業務未啟動
- 時刻 1 ，在第 5 秒時，離線業務上線。此時在離線業務開始競争網絡資源
- 時刻 2 ，在第 10 秒時，線上業務下線。此時僅留離線業務繼續運作
- 時刻 3 ，在第 15 秒時，線上業務上線。此時在離線業務再次競争網絡資源
- 時刻 4 ，在第 20 秒時，離線業務下線。此時僅留線上業務繼續運作
- 在測試過程中，持續觀測 Node1 上業務容器的網絡帶寬使用情況。
通過采集未開啟/開啟 Pod 網絡帶寬管理特性兩輪測試的測試資料，獲得曲線圖如下。可見：
- 時刻 1 時，離線業務開始競争網絡資源。在測試 1 ，線上業務的帶寬受到了影響；而測試 2 ，線上業務的帶寬幾乎不受影響；
- 時刻 2 時，線上業務停止處理請求。在測試 2 裡，之前一直被壓制的離線業務，終于獲得更多的網絡帶寬；
- 時刻 3 時，線上業務恢複處理請求。測試 2 的線上業務馬上獲得了盡可能多的網絡帶寬，同時離線業務的帶寬受到了壓制。相比之下，測試 1 的線上業務始終沒法獲得充足的網絡帶寬；
- 時刻 4 時，離線業務停止競争網絡資源。此時測試 1 的線上業務才可以獲得足夠的網絡帶寬
由上測試可見，通過 openEuler 混部 QoS 方案的 Pod 網絡帶寬管理特性，當在離線業務競争網絡資源的時候，線上業務能夠在百毫秒内實作帶寬資源的搶占，快速獲得急需的網絡帶寬資源，進而保障了線上業務的 QoS。
總結
通過上面的四個案例，我們為大家展示了 openEuler 的資源使用率提升方案可以為線上業務帶來的一些收益：即在提升節點資源使用率的時候，通過多元度資源優先級隔離和自動幹擾控制保證關鍵線上業務的服務品質。
接下來，我們會在後續的系列文章中逐一為大家帶來關鍵特性的技術剖析。
參考
- openEuler 資源使用率提升之道 01 ：概論：https://mp.weixin.qq.com/s/x9sdogEslRJJ5mDbs5bxgQ
- CloudSuite | A Benchmark Suite for Cloud Services：https://www.cloudsuite.ch/
- Web Serving：https://github.com/parsa-epfl/cloudsuite/blob/main/docs/benchmarks/web-serving.md
- In-Memory Analytics：https://github.com/parsa-epfl/cloudsuite/blob/main/docs/benchmarks/in-memory-analytics.md
- iPerf - The TCP, UDP and SCTP network bandwidth measuremen t tool：https://iperf.fr/
系列文章回顧
openEuler 資源使用率提升之道 01 ：概論：https://mp.weixin.qq.com/s/x9sdogEslRJJ5mDbs5bxgQ