在本系列的第一篇中，我們看到了 Linux 系統管理員視角下的 Cgroup，並瞭解了它如何幫助資源管理和效能調優。

在第二篇中，作者將繼續介紹 CPUShares 以及它如何幫助管理 Cgroup，那麼我們現在開始。

一、Linux I/O 排程

首先，我想用紅帽企業版 Linux（RHEL）來簡單介紹一下 Linux 的 I/O 排程程式。我簡單看了一下實驗室裡的幾臺 Ubuntu 機器，發現它們的 I/O 排程程式有一些相似之處，所以我下面的一些觀點可能也適用於其他發行版本。紅帽系列產品（Fedora、CentOS 和 RHEL）大多數都預設使用  cfq 或  deadline 作為排程程式。 

• CFQ（完全公平佇列演算法）：強調 I/O 實時程式，並使用歷史資料來決定應用程式是否會在近期發出更多的 I/O 請求。

• Deadline（最後期限演算法）：嘗試為 I/O 請求提供有保障的延遲，特別適合於讀取操作比寫入操作更頻繁的情況。在 deadline 排程程式中，讀和寫分別有一個佇列，機器根據請求在佇列中等待的時間來決定處理順序。同時，核心會盡力在請求的最大等待時間耗盡之前處理它們。預設情況下，讀操作優先於寫操作處理。

在預設情況下，RHEL 對 SATA 驅動器使用  cfq 排程程式，對其他驅動器使用  deadline 排程程式，以便更好地調優系統。

當然，這些排程程式也是可以更改的，我們可以根據工作負載選擇最適合的排程程式。另外，還可以針對每個塊裝置選擇排程程式。也就是說，在單個系統上可以有多個排程程式，具體取決於磁碟的配置方式。

二、CPUShares 及其用途

CPUShares 為 Cgroup 中的任務分配了相對的 CPU 時間。只要系統掛載了 Cpu Cgroup 控制器，您就可以使用  cpu.shares 檔案來定義分配給 Cgroup 的 CPU 份額。

CPU 時間可以透過 Cgroup 的 CPUShares 值除以系統上定義的總 CPUShares 值來確定。這個 CPU 時間的計算有些複雜，下面我們來看一些例項以便更好地理解。

上圖展示了 RHEL 7 OpenShift 容器平臺控制平面上的一些常見元素。這個系統上的每個程式都從根目錄的  / Cgroup 開始。

在 RHEL 中，從根目錄的  / Cgroup 開始，共有 1024 個份額和 100% 的 CPU 資源。剩下的資源被平均分配給  /system.slice、 /user.slice 和  /kubepod.slice 這些組，每個組預設的權重都是 1024，如下圖所示：

在這種情況下，計算的邏輯很簡單：如果所有 Cgroup 同時要求資源，每個 slice 只能擁有 33% 的 CPUShares。數學計算就是：

代入數字：

然而，如果我們想要巢狀組或更改同一級別組的權重，會發生什麼呢？下面就是一個巢狀組的示例：

可以看到我為不同的使用者建立了一個 Cgroup，然後計算就不一樣了。你可能會這麼計算：

那就錯了。其實該使用者佔到的份額是  user.slice 分配到的 33% 的 23%。也就是說，在資源爭用的情況下， user1 大約可以佔總 CPU 時間的 7.6%。

因此，CPUShares 的計算其實沒那麼簡單。不過，好訊息是，絕大多數控制器比這裡展示的要更加直觀簡單，所以大可不必擔心。

三、總結

CPUShares 可能會讓 Cgroup 變得非常複雜，這也是我認為有必要在這裡介紹它的一個原因。而如果掌握了 CPUShares 的內在邏輯，且可以正確地使用它的話，能夠極大地幫助您有效、準確地管理系統。

在之後的系列文章中，我還將繼續討論 Cgroup 的管理，以及 systemd 的使用問題。敬請期待哦。