如何在 Ubuntu 上使用 Cgroups 限制進程的 CPU 和記憶體使用量

在 Ubuntu 系統中，使用 cgroups 限制工作負載最安全的方法是讓 systemd 建立和管理其控制群組。systemd-run您可以將其用於目前啟動的命令，或設定 systemd 服務以確保重新啟動後限制仍然有效。您可以設定CPUQuota=CPU 時間上限，並根據需要選擇記憶體限制MemoryHigh=（用於應對壓力）或MemoryMax=CPU 記憶體限制（用於應對記憶體壓力）。這些限制同時適用於該單元及其子程序。

cgroup（控制組）是 Linux 核心的一種機制，用於組織進程，以便系統能夠統計和控制它們的資源使用情況。 Ubuntu 的 systemd 已經將服務放置在 cgroup 中，因此大多數使用者無需手動建立目錄/sys/fs/cgroup。以下範例使用 systemd 的資源控制接口，應根據您 Ubuntu 發行版上安裝的 systemd 版本進行檢查。

一個 Ubuntu 風格的終端模擬程序，在設定資源限制之前檢查 systemd 版本和 cgroup2fs 掛載類型。 — 用於檢查 systemd 和 cgroup v2 掛載的終端機範例。顯示的版本和輸出僅為範例，並非實際測試結果。

選擇與問題相符的控制項。

方法	它控制著什麼	最佳匹配	主要權衡
`systemd-run`瞬態範圍	新啟動的命令及其子命令的 CPU 配額和記憶體限制	建置、腳本、匯入或一次批次作業	這個作用域是暫時的，會隨著工作負載的完成而結束；它不會附加到任何已經在執行的進程上。
systemd 服務設定	服務 cgroup 的資源，包括子進程	重啟後應保持相同限制的守護進程或應用程式	需要進行服務配置，通常還需要重新啟動服務才能套用新設定。
直接 cgroup v2 文件	內核級控制器，例如`cpu.max`和`memory.max`	容器運行時、委託的 cgroup 管理器或專門的管理	需要更多手動操作；systemd 擁有 Ubuntu 大部分層級結構，寫入其管理的樹可能會與 systemd 衝突，或由於權限和委派而失敗。
`nice`或者`CPUWeight=`	組間競爭時的相對 CPU 優先權	降低後台工作的優先級，同時允許其使用空閒的 CPU	這並非CPU的硬性限制，也不會限制記憶體。

對於大多數互動式 Ubuntu 系統，瞬態作用域是最快捷且可逆的選擇。對於生產服務，請使用服務單元，以便策略可以得到記錄並在啟動時恢復。只有當您有意管理委託層次結構或建置容器/執行時間工作流程時，才應使用直接的 cgroup 檔案。

設定限制前請檢查 Ubuntu 系統。

首先檢查 systemd 是否可用，以及 cgroup 檔案系統是否為統一版本 2：

systemctl --version
stat -fc %T /sys/fs/cgroup

第二個指令的結果cgroup2fs顯示使用的是統一的 cgroup v2 檔案系統。 Ubuntu 發行版和自訂系統可能存在差異，因此不要假設每台機器都具有相同的層級結構或 systemd 功能。您也可以使用第一個指令檢查目前的 systemd 版本。如果 cgroup 掛載點不是 v2，則某些資源屬性或控制器行為可能會有所不同；在複製配置之前，請參閱已安裝版本的 Ubuntu 手冊頁。

在評估工作負載後再選擇適當的值。為系統其他部分預留空間，並記住，使用者服務的限制也受其父級切片限制的約束。子級 cgroup 所獲得的資源不能超過其父級 cgroup 允許的資源。

限制即將開始的命令

對於您目前使用者會話中的命令，請使用 `--transient-scope` 在瞬態作用域中啟動它systemd-run --user --scope。例如：

一個 Ubuntu 風格的終端模擬程序，啟動一個 Python 工作進程，CPU 使用率限制為 50%，記憶體閾值分別為 700 MB 和 900 MB。 — 一個範例終端模型，展示了一次性 systemd-run 命令，該命令具有 CPU 配額、記憶體壓力閾值和記憶體上限。

systemd-run --user --scope --unit=worker-capped \
  -p CPUQuota=50% \
  -p MemoryHigh=700M \
  -p MemoryMax=900M \
  -- python3 /opt/worker.py

將 Python 命令替換為您實際需要執行的程式。此範例為 cgroup 分配了相當於半個 CPU 的最大 CPU 頻寬，在記憶體使用量達到 700 MiB 左右時開始進行記憶體壓力處理，並設定了 900 MiB 的硬性記憶體上限。記憶體值採用 systemd 的 1024 進位單位。配額100%表示最多可以使用一個 CPU 的時間；200%在可用時最多可以使用兩個 CPU 的時間。這並不意味著計算機中所有核心的百分比。

該命令在前台運行，因為這是一個作用域。命令退出後，臨時單元將消失。--user僅當您打算使用系統管理員並擁有所需權限時才可移除；對於系統範圍的臨時單元，請執行該命令sudo並使用相應的命令選項。如果管理器或 cgroup 控制器不支援資源設置，則這些設定可能會被拒絕。

設定持久性 systemd 服務的限制

對於類似這樣的服務worker.service，請建立一個插入式配置，而不是編輯供應商單元檔案。運行sudo systemctl edit worker.service並添加：

包含 CPUQuota、MemoryHigh 和 MemoryMax 設定的 systemd 服務設定範例 — 這是一個範例 systemd 服務配置，其中包含持久的 CPU 和記憶體控制。請使用實際的服務名稱和適合您工作負載的值。

[Service]
CPUQuota=50%
MemoryHigh=700M
MemoryMax=900M

儲存此替換文件，然後重新載入 systemd 的單元定義並重新啟動服務，以便進程在修改後的策略下啟動：

sudo systemctl daemon-reload
sudo systemctl restart worker.service

謹慎設定內存上限。如果服務無法回收足夠的內存MemoryMax，核心可能會呼叫該 cgroup 內的記憶體溢位終止程式。這可能會終止服務組中的一個或多個進程，並中斷工作。更安全的做法通常是先將記憶體上限設定為一個MemoryHigh可以接受記憶體回收和節流的水平，然後再將上限提高到MemoryMax更高的水平作為最終邊界。在部署嚴格的記憶體上限之前，請使用實際尖峰負載進行測試。

檢查設備並觀察其運作情況

對於瞬態範圍，請使用您提供的單元名稱檢查其狀態：

終端模型展示了 systemctl 狀態和 systemd-cgtop 對瞬態工作負載範圍的監控。 — 狀態和 cgroup 監視器視圖示意圖。此處顯示的 CPU 和記憶體資料並非實際運行的測量結果。

systemctl --user status worker-capped.scope
systemd-cgtop

對於系統服務，--user狀態指令中可以省略參數。狀態視圖會確認單元存在且處於活動狀態；systemd-cgtop並顯示控制組的即時資源使用情況。若要檢查已配置的屬性，請直接查詢單元，例如：

systemctl --user show worker-capped.scope \
  -p CPUQuotaPerSecUSec -p MemoryHigh -p MemoryMax

針對 cgroup 報告的記憶體佔用量並不一定與單一進程的駐留記憶體集相同：它統計的是分配給該 cgroup 的內存，並且可能包含工作負載的子程序的記憶體。應將監控結果視為該工作負載隨時間推移的行為特徵，而不是盲目優化的單一數值。

如果進程已經在運作了怎麼辦？

systemd-run它會在一個新的單元內啟動一個新指令；它不會將任意現有的進程 ID (PID) 移到該作用域內。如果該程序屬於 systemd 服務，請使用 drop-in 將設定套用到該服務，或者，對於臨時更改，請使用sudo systemctl set-property --runtime worker.service CPUQuota=50% MemoryHigh=700M MemoryMax=900M。此--runtime方法為臨時方法，不會取代持久性服務配置。

如果該進程是桌面會話中的常規程序，通常安全簡單的方法是停止它，然後重新啟動systemd-run。將屬性應用於更廣泛的範圍（例如整個使用者分區）可能會影響許多不相關的應用程式。透過將進程 ID (PID) 寫入 cgroup 檔案來移動進程需要控制相關的委託層次結構，並且必須遵守 cgroup v2 進程放置規則；切勿憑猜測寫入 systemd 管理的目錄。

如何選擇 CPU 和記憶體策略

需要設定 CPU 使用率上限？請選擇此項CPUQuota=。較低的值可以降低 CPU 使用率峰值，但可能會減慢任務完成速度並增加排隊時間。
只需要較低優先權？不妨考慮CPUWeight=權重分配，而不是配額分配。權重分配是指在 CPU 資源競爭中相對公平地分配 CPU 資源；它不會預留固定百分比的資源，也不會阻止使用閒置的 CPU 資源。
需要記憶體壓力但又不想立即強制停止？將其設定MemoryHigh=為主要壓力閾值，並觀察延遲和記憶體回收行為。
需要設定最終的約束邊界嗎？請預留MemoryMax=足夠的空間以應對正常的峰值流量。如果邊界無法滿足要求，請做好應對記憶體溢位（OOM）行為的準備。
已經在使用容器？建議使用容器管理器支援的 CPU 和記憶體標誌，這些標誌會為該容器配置 cgroups 並適應其生命週期。

沒有一個適用於所有工作負載的理想限制。桌面批次作業可能只需較低的配額和適中的記憶體上限；而對延遲敏感的服務可能需要更大的 CPU 餘裕和更高的記憶體上限，MemoryHigh以避免因記憶體回收而導致的暫停。建議從保守的設定開始，在典型的尖峰負載期間監控設備，並每次只調整一個設定。