內存Cgroup創建原理：從內核機制到實踐應用

作者：深度Linux 2025-10-11 04:11:00

Cgroups（Control Groups）是 Linux 內核提供的物理資源隔離機制，通過層級化的控制組（Control Group）實現對進程組的資源限制、統計與隔離。它就像是一個精密的資源分配器，把系統資源（如 CPU、內存、磁盤 I/O 等）按照不同的規則，精準地分配給各個進程組。

在容器化和微服務架構里，你是否常遇到這些困惑：Docker 容器突然因內存溢出被 OOM Killer 終止？Kubernetes 集群中 Pod 間的內存爭搶拖慢整個服務？其實，解決這些問題的核心底層技術，正是 Linux 內核的內存 cgroup（Control Group 內存子系統）—— 它不僅是容器實現內存配額的 “隱形管家”，更是保障分布式系統資源穩定的關鍵支撐。很多開發者熟悉用--memory給 Docker 設限，卻不清楚背后如何從內核層面攔截內存分配、統計資源使用；運維同學面對 cgroup 目錄下的memory.limit_in_bytes等文件，也常困惑參數配置的底層邏輯。

先拆解內存 cgroup 的創建全流程（從文件系統掛載到進程綁定），再深扒內核中mem_cgroup數據結構、OOM 處理機制等核心原理，還會結合 Docker/K8s 的實戰配置案例，對比 cgroup v1/v2 差異，給出生產環境優化建議。無論你是想搞懂容器內存隔離的底層邏輯，還是需要解決資源管控的實際問題，跟著內容一步步拆解，都能理清內存 cgroup 的 “來龍去脈”。

一、什么是內存 cgroup ？

1.1 cgroup 概述

想象一下，你的服務器是一個大型公寓，里面有很多租客（進程）。cgroup 就像是公寓管理員，它把租客們分成不同的小組（控制組），然后為每個小組分配不同的資源額度。比如，有些小組可能被允許使用更多的 CPU 資源，就像一些租客被分配到了更大的房間；而有些小組可能被限制了內存使用量，就像一些租客的水電費被限制了額度。

Cgroups 最早是由 Google 的工程師在 2006 年發起的，當時叫作 “進程容器”（Process Container），在 2007 年被重命名為 cgroups，并在 2008 年合并到 2.6.24 版內核后正式對外發布，這一階段的 cgroups 被稱為 “第一代 cgroups”。隨著技術的發展，在 2016 年 3 月發布的 Linux Kernel 4.5 版本中，搭載了由 Facebook 工程師重新編寫的 “第二代 cgroups”，使得管理員能更加清晰、精確地控制資源的層級關系。

內存 cgroup 作為 cgroups 子系統之一，專注于內存資源的精細化管理，是 Docker、Kubernetes 等容器技術實現內存配額控制的核心底層技術。在容器化的世界里，每個容器都像是一個獨立的小公寓，內存 cgroup 確保每個容器都能在自己的內存配額內運行，不會出現某個容器過度占用內存，導致其他容器無法正常工作的情況。

對于內核開發者或好奇者來說，內存Cgroup的實現代碼位于 Linux內核源代碼樹 中。

主要代碼路徑： linux/mm/memcontrol.c
頭文件： linux/memcontrol.h

在Linux內核運行時，每個進程的 task_struct（進程描述符）中都有一個指針指向其所屬的cgroup。

// 在 task_struct 中（簡化表示）
struct task_struct {
    // ...
    struct css_set __rcu *cgroups; // 指向cgroup組的集合
    // ...
};

而每個cgroup本身在內核中也是一個復雜的數據結構（struct mem_cgroup），它維護了該組內所有進程的內存使用統計、限制、計數器等。所以，從任何一個進程出發，都可以找到其對應的內存Cgroup控制結構。

1.2虛擬文件系統驅動的管控邏輯

解內存 Cgroup 的定義，需深入其底層實現本質 —— 它并非獨立的 “程序”，而是依托 Linux 虛擬文件系統（VFS）構建的配置與管控接口集合。其本質邏輯可概括為兩點：

（1）以文件為 “配置入口”：內存 Cgroup 的所有管控操作，均通過/sys/fs/cgroup/memory/目錄下的虛擬文件完成。例如：

創建控制組：在該目錄下新建子目錄（如mkdir /sys/fs/cgroup/memory/app1），系統會自動生成memory.limit_in_bytes（內存硬限制）、cgroup.procs（組內進程 PID 列表）等默認配置文件；
修改內存限制：向memory.limit_in_bytes寫入數值（如echo 100M > 該文件路徑），即可實時生效；
綁定進程：向cgroup.procs寫入進程 PID（如echo 1234 > 該文件路徑），即可將進程納入控制組管控。

（2）內核層 “實時攔截與調控”：當進程屬于某個內存 Cgroup 時，其每一次內存申請 / 釋放操作，都會被 Linux 內核的內存管理模塊攔截，對照該控制組的配置（如限制值、隔離規則）進行校驗：

若申請內存未超限制：正常分配；
若超硬限制：觸發 OOM（Out Of Memory）機制，優先殺死組內低優先級進程；
若超軟限制且系統內存緊張：優先回收該組的超額內存。

這種 “文件配置 + 內核攔截” 的本質，讓內存 Cgroup 具備了 “輕量化、可動態調整、無額外性能損耗” 的特點。

1.3內存 cgroup 核心功能

（1）資源限制：通過memory.limit_in_bytes設定內存使用上限，超出時觸發 OOM Killer 機制終止進程。就好比給每個進程組分配了一個固定大小的 “內存口袋”，當進程組往這個口袋里裝的東西（使用的內存）超過口袋的容量時，OOM Killer（Out-Of-Memory Killer）就會像一個嚴厲的警察一樣出現，把占用內存過多的進程給 “抓起來”（終止掉），以保證系統的穩定性。例如，在一個多容器的 Kubernetes 集群中，如果某個容器的內存使用量超過了memory.limit_in_bytes設定的上限，Kubernetes 就會根據 OOM Killer 的策略，選擇終止這個容器內的某些進程，甚至直接殺掉整個容器，以釋放內存資源給其他容器使用。

（2）使用統計：通過memory.usage_in_bytes實時監控內存占用，支持內存 + 交換空間（memsw）的聯合統計。這就像是給每個進程組配備了一個 “內存用量計數器”，可以隨時查看進程組當前使用了多少內存。同時，它還能把內存和交換空間（就像是內存不夠用時的 “備用倉庫”）的使用情況一起統計起來，讓管理員對進程組的內存使用情況有更全面的了解。比如，在排查系統性能問題時，管理員可以通過查看memory.usage_in_bytes和memory.memsw.usage_in_bytes的值，判斷某個進程組是否存在內存泄漏或者過度使用交換空間的情況。

（3）層級繼承：子控制組自動繼承父組的內存配置，支持多級資源配額管理。這就像一個家族企業，家族的規則（內存配置）會從長輩（父控制組）傳遞給晚輩（子控制組）。通過這種層級繼承的方式，可以方便地實現對不同層次的進程組進行統一的內存管理。例如，在一個大型的分布式系統中，可能會有多個服務模塊，每個服務模塊又包含多個子模塊。可以通過創建一個父控制組，為整個服務模塊設定一個總的內存配額，然后為每個子模塊創建子控制組，這些子控制組會自動繼承父控制組的內存配置，同時還可以根據子模塊的實際需求，對內存配額進行進一步的微調。

（4）壓力通知：通過memory.pressure_level接口實時反饋內存壓力狀態，輔助內核調度決策。這就像是給系統安裝了一個 “內存壓力報警器”，當內存壓力達到一定程度時，它會及時發出警報，告訴內核現在內存有點緊張了，需要調整調度策略，比如優先調度那些內存使用較少的進程，或者把一些不常用的數據從內存中換到交換空間中，以緩解內存壓力。比如，在一個高并發的 Web 服務器環境中，當大量用戶同時訪問服務器時，內存使用量可能會迅速上升。此時，memory.pressure_level就會向內核反饋內存壓力狀態，內核根據這個反饋，調整進程的調度優先級，保證關鍵業務進程有足夠的內存可用，避免因為內存不足導致服務器響應變慢甚至崩潰。

二、內存 cgroup 創建核心流程解析

2.1cgroup 文件系統掛載（初始化）

在使用內存 cgroup 之前，首先要進行 cgroup 文件系統的掛載，這一步就像是為內存 cgroup 搭建一個 “工作場地”。通過mount -t cgroup -o memory memory /sys/fs/cgroup/memory這條命令，我們把內存子系統掛載到了/sys/fs/cgroup/memory這個指定目錄上。這就好比在一個大倉庫（文件系統）里劃分出了一個專門的區域（掛載目錄），用來存放與內存 cgroup 相關的 “物品”。

掛載完成后，在這個掛載目錄下會生成一系列文件接口，這些文件接口就像是一個個控制開關，我們可以通過它們來對內存 cgroup 進行各種操作。比如memory.limit_in_bytes文件，它就像是一個 “內存上限控制器”，我們可以通過修改這個文件的值，來設定某個控制組可以使用的最大內存量；還有cgroup.procs文件，它就像是一個 “進程收納箱”，我們把進程的 PID（進程標識符，就像是每個進程的身份證號碼）寫入這個文件，就可以把對應的進程加入到這個控制組中，讓這個進程受到該控制組內存配置的管理。

同時，在掛載時會自動創建一個根控制組（root cgroup）。這個根控制組就像是一個大家族的族長，它包含了系統中所有的進程，是整個控制組層級結構的根基。根控制組的內存配置就像是家族的基本家規，會作為后續創建的子控制組的默認模板。當我們創建子控制組時，如果沒有特別指定內存配置，子控制組就會自動繼承根控制組的內存配置。例如，根控制組設置了內存使用的軟限制和硬限制，那么新創建的子控制組在沒有額外設置的情況下，也會遵循這些限制。

內存 cgroup 的 bash 腳本示例如下：

#!/bin/bash

# 檢查cgroup內存子系統是否已掛載
if ! mountpoint -q /sys/fs/cgroup/memory; then
    echo "正在掛載cgroup內存子系統..."
    sudo mount -t cgroup -o memory memory /sys/fs/cgroup/memory
    if [ $? -ne 0 ]; then
        echo "掛載失敗，請檢查權限和系統配置"
        exit 1
    fi
fi

# 創建一個名為my_memory_group的子控制組
CGROUP_DIR="/sys/fs/cgroup/memory/my_memory_group"
echo "創建子控制組: $CGROUP_DIR"
sudo mkdir -p $CGROUP_DIR

# 設置內存限制為512MB (512 * 1024 * 1024 = 536870912字節)
echo "設置內存限制為512MB"
sudo sh -c "echo 536870912 > $CGROUP_DIR/memory.limit_in_bytes"

# 設置內存軟限制為256MB
echo "設置內存軟限制為256MB"
sudo sh -c "echo 268435456 > $CGROUP_DIR/memory.soft_limit_in_bytes"

# 啟動一個測試進程并將其加入控制組
echo "啟動測試進程并加入控制組..."
sleep 300 &  # 啟動一個睡眠300秒的進程作為示例
PID=$!
echo "將進程PID $PID 加入控制組"
sudo sh -c "echo $PID > $CGROUP_DIR/cgroup.procs"

# 顯示控制組當前狀態
echo "當前控制組狀態:"
echo "內存限制: $(cat $CGROUP_DIR/memory.limit_in_bytes) 字節"
echo "內存軟限制: $(cat $CGROUP_DIR/memory.soft_limit_in_bytes) 字節"
echo "控制組中的進程: $(cat $CGROUP_DIR/cgroup.procs)"

# 等待用戶輸入后清理資源
read -p "按任意鍵停止測試并清理資源..."

# 終止測試進程
echo "終止測試進程 $PID"
sudo kill $PID 2>/dev/null

# 清理創建的控制組
echo "清理控制組 $CGROUP_DIR"
sudo rmdir $CGROUP_DIR

echo "演示完成"

這個腳本演示了內存 cgroup 的基本使用流程：

首先檢查 cgroup 內存子系統是否已掛載，如果沒有則進行掛載
創建一個名為my_memory_group的子控制組
為該控制組設置 512MB 的內存硬限制和 256MB 的內存軟限制
啟動一個測試進程（sleep 300）并將其 PID 加入到控制組中
顯示當前控制組的配置信息
等待用戶確認后，清理創建的進程和控制組

使用時需要注意：

運行腳本需要 root 權限（使用 sudo）
不同系統的 cgroup 路徑可能略有差異
清理步驟很重要，避免留下無用的控制組
實際使用中可以根據需要修改內存限制值和測試進程

2.2控制組創建與參數配置

當 cgroup 文件系統掛載完成后，就可以開始創建具體的控制組并進行參數配置了。創建子控制組非常簡單，只需要在掛載目錄下創建一個子目錄就行。比如執行sudo mkdir /sys/fs/cgroup/memory/myapp，這樣就在/sys/fs/cgroup/memory目錄下創建了一個名為myapp的子控制組。這就好比在前面劃分好的專門區域里，又隔出了一個小房間，用來放置特定的 “物品”（進程）。在創建這個子目錄的同時，內核會自動為這個控制組生成專屬的配置文件，就像是給這個小房間配備了一套專屬的管理規則。

接下來就是關鍵的參數配置環節了，這一步決定了控制組內進程的內存使用規則。

硬限制設置：通過echo 1073741824 > memory.limit_in_bytes這樣的命令，我們可以設置內存使用的硬限制。這里的1073741824是字節數，換算過來就是 1GB，這就意味著這個控制組內的所有進程，總共最多只能使用 1GB 的內存。當進程使用的內存達到這個限制時，如果再嘗試申請更多內存，就會觸發 OOM Killer 機制，相關進程可能會被終止，以保證系統的穩定性。就像一個杯子，它的容量是固定的（硬限制），當水（內存使用）裝滿了這個杯子，就再也裝不下更多的水了，再往里倒水（申請內存）就會溢出來（觸發 OOM Killer）。
軟限制設置：memory.soft_limit_in_bytes參數用于設置軟限制。軟限制允許進程在一定時間內臨時超額使用內存，這就像是給進程一個 “彈性額度”。比如某個進程在業務高峰期，可能會短暫地需要更多內存，軟限制就可以滿足這種臨時需求。但是這個彈性額度是有限的，它需要配合memory.limit_in_bytes硬限制來使用。當進程使用的內存超過軟限制但還未達到硬限制時，系統會根據內存壓力等情況，對進程進行相應的處理，比如降低進程的內存分配優先級，或者在內存緊張時回收部分內存。這就好比信用卡有一個固定的信用額度（硬限制），同時還有一個臨時額度（軟限制），在臨時額度內可以暫時多消費一些，但最終還是不能超過固定信用額度。
交換空間控制：通過echo 0 > memory.swappiness命令，可以禁止控制組內的進程使用交換分區。交換分區就像是內存不夠用時的 “備用倉庫”，把暫時不用的數據存放到交換分區，以騰出內存空間。但是使用交換分區會帶來性能損耗，因為從磁盤（交換分區所在的存儲設備）讀寫數據比從內存讀寫數據要慢得多。所以當我們設置memory.swappiness為 0 時，就像是把這個 “備用倉庫” 的門給關上了，確保內存限制的嚴格生效，避免因為使用交換分區而導致內存限制被繞過的情況。例如，在對性能要求極高的實時計算場景中，就需要嚴格控制內存使用，避免使用交換分區帶來的性能波動。

2.3進程關聯與動態管理

創建好控制組并配置好參數后，就需要把進程關聯到控制組中，讓進程受到控制組內存配置的管理，并且在運行過程中還需要對進程進行動態管理。

添加進程到控制組的操作也很簡單，通過echo <PID> > cgroup.procs命令，把目標進程的 PID 寫入控制組的cgroup.procs文件中，就可以把這個進程添加到對應的控制組中。這就像是把一個員工（進程）分配到一個特定的項目組（控制組）中，讓他遵循這個項目組的規則（內存配置）工作。這個操作還支持批量添加，只需要不斷地把不同進程的 PID 追加寫入cgroup.procs文件即可，就像一次把多個員工分配到同一個項目組。

同時，如果開啟了cgroup.clone_children選項，子進程會自動繼承父進程所在的控制組。這就好比一個家族企業中，父親（父進程）在某個部門（控制組）工作，他的子女（子進程）出生后（創建后）也會自動進入這個部門工作。例如，在一個 Web 服務器應用中，主進程創建了多個子進程來處理不同的用戶請求，開啟cgroup.clone_children后，這些子進程會自動繼承主進程所在控制組的內存配置，確保整個應用的內存使用是可控的。

在進程運行過程中，還支持運行中進程跨控制組遷移，這一特性在很多場景下都非常有用。通過修改cgroup.procs文件，把進程的 PID 從一個控制組的cgroup.procs文件移動到另一個控制組的cgroup.procs文件中，就可以實現進程的跨控制組遷移。這就像是一個員工從一個項目組調到另一個項目組，他需要遵循新的項目組規則（新控制組的內存配置）。例如，在微服務架構中，當某個微服務的負載突然增加，需要更多的內存資源時，可以通過將該微服務相關的進程遷移到一個內存配額更大的控制組中，實現動態資源重分配，保證微服務的正常運行，這對于實現微服務的彈性擴縮容非常關鍵。

進程添加到控制組、子進程繼承以及進程遷移功能的 bash 腳本示例：

#!/bin/bash

# 確保以root權限運行
if [ "$(id -u)" -ne 0 ]; then
    echo "請使用root權限運行此腳本 (sudo)"
    exit 1
fi

# 檢查并掛載cgroup內存子系統
CGROUP_MOUNT="/sys/fs/cgroup/memory"
if ! mountpoint -q $CGROUP_MOUNT; then
    echo "掛載cgroup內存子系統..."
    mount -t cgroup -o memory memory $CGROUP_MOUNT
    if [ $? -ne 0 ]; then
        echo "掛載失敗"
        exit 1
    fi
fi

# 創建兩個測試控制組
GROUP1="$CGROUP_MOUNT/group1"
GROUP2="$CGROUP_MOUNT/group2"

echo "創建控制組..."
mkdir -p $GROUP1 $GROUP2

# 為不同控制組設置不同的內存限制
echo "配置控制組內存限制..."
echo 268435456 > $GROUP1/memory.limit_in_bytes  # 256MB
echo 536870912 > $GROUP2/memory.limit_in_bytes  # 512MB

# 1. 演示添加進程到控制組
echo -e "\n=== 演示添加進程到控制組 ==="
sleep 300 &
PID1=$!
echo "將進程 $PID1 添加到 group1"
echo $PID1 > $GROUP1/cgroup.procs
echo "group1 中的進程: $(cat $GROUP1/cgroup.procs)"

# 2. 演示批量添加進程
echo -e "\n=== 演示批量添加進程 ==="
sleep 300 &
PID2=$!
sleep 300 &
PID3=$!
echo "批量添加進程 $PID2 和 $PID3 到 group1"
echo $PID2 >> $GROUP1/cgroup.procs
echo $PID3 >> $GROUP1/cgroup.procs
echo "group1 中的進程: $(cat $GROUP1/cgroup.procs)"

# 3. 演示子進程繼承控制組 (cgroup.clone_children)
echo -e "\n=== 演示子進程繼承控制組 ==="
echo "開啟 group1 的 clone_children 選項"
echo 1 > $GROUP1/cgroup.clone_children

echo "在 group1 中啟動一個父進程，該進程會創建子進程"
(
    # 這個腳本在group1中運行，會創建子進程
    echo "父進程 PID: $$ 在控制組: $(cat /proc/$$/cgroup | grep memory | cut -d: -f3)"
    sleep 300 &  # 子進程1
    sleep 300 &  # 子進程2
    wait
) &
PID_PARENT=$!
echo $PID_PARENT > $GROUP1/cgroup.procs

# 等待子進程創建
sleep 2
echo "group1 中的進程（包含子進程）: $(cat $GROUP1/cgroup.procs)"

# 4. 演示進程遷移
echo -e "\n=== 演示進程遷移 ==="
echo "將進程 $PID1 從 group1 遷移到 group2"
echo $PID1 > $GROUP2/cgroup.procs

echo "group1 中的進程: $(cat $GROUP1/cgroup.procs)"
echo "group2 中的進程: $(cat $GROUP2/cgroup.procs)"

# 等待用戶輸入，觀察效果
read -p "按任意鍵繼續清理資源..."

# 清理操作
echo -e "\n清理資源..."

# 終止所有測試進程
echo "終止測試進程..."
for pid in $(cat $GROUP1/cgroup.procs $GROUP2/cgroup.procs); do
    kill $pid 2>/dev/null
done

# 刪除控制組
echo "刪除控制組..."
rmdir $GROUP1 $GROUP2

echo "演示完成"

這個腳本展示了 cgroup 進程管理的幾個關鍵功能：

添加進程到控制組：通過將 PID 寫入 cgroup.procs 文件，將進程納入控制組管理
批量添加進程：通過追加方式將多個 PID 寫入 cgroup.procs，實現批量管理
子進程繼承：通過開啟 cgroup.clone_children 選項，使子進程自動繼承父進程的控制組
進程遷移：通過將 PID 從一個控制組的 cgroup.procs 文件移動到另一個，實現進程在不同控制組間的遷移

腳本使用了兩個不同內存限制的控制組（256MB 和 512MB），以便清晰展示進程在不同控制組間遷移的效果。實際使用時，可以根據需要調整內存限制值和測試進程類型。

運行此腳本需要 root 權限，因為 cgroup 操作通常需要管理員權限。完成演示后，腳本會自動清理創建的進程和控制組，避免系統資源殘留。

三、內存 cgroup 內核實現關鍵機制

3.1內存統計與監控原理

（1）數據結構支撐：在內核層面，內存 cgroup 的狀態維護依賴于一系列精心設計的數據結構，其中struct mem_cgroup扮演著核心角色。它就像是內存 cgroup 的 “管家”，全面記錄著控制組的各種內存相關狀態信息。struct mem_cgroup中包含一個page_counter類型的成員，專門用于精準統計內存使用量，它會實時跟蹤控制組內進程對內存的占用情況，就像一個精準的 “內存用量計數器”，時刻更新著內存使用的數值。

同時，vmstats_percpu數據結構記錄各 CPU 核心的內存開銷情況，像常駐內存集（RSS，Resident Set Size）、頁緩存（Page Cache）等關鍵指標都被詳細記錄其中。不同 CPU 核心上的內存使用情況可能會因為進程的分布和執行情況而有所不同，vmstats_percpu就像是為每個 CPU 核心配備了一個專屬的 “內存使用記錄員”，分別記錄它們的內存開銷，為系統提供了更細致的內存使用數據，幫助系統管理員更全面地了解內存使用的分布情況。

（2）實時統計接口：內存 cgroup 提供了豐富的實時統計接口，方便用戶獲取內存使用的詳細信息。memory.stat文件就是其中一個重要的接口，它提供了極為詳細的統計數據，涵蓋了活躍匿名內存（active_anon）、非活躍文件內存（inactive_file）等多個維度。活躍匿名內存反映了正在被進程積極使用且未與文件關聯的內存量，而非活躍文件內存則表示那些雖然與文件相關聯，但當前處于非活躍狀態的內存量。這些數據對于深入分析內存使用情況非常關鍵，比如通過對比活躍匿名內存和非活躍文件內存的大小，系統管理員可以判斷內存中的數據是更多地被進程直接使用，還是更多地以文件緩存的形式存在，從而為內存優化提供依據。

memory.max_usage_in_bytes文件記錄了控制組歷史峰值內存使用量，這一數據在容量規劃和異常診斷中發揮著重要作用。在進行系統容量規劃時，了解控制組曾經達到的最大內存使用量，可以幫助管理員合理分配內存資源，避免未來因為內存不足而導致系統故障。

例如，在一個電商系統中，在促銷活動期間，某些服務的內存使用量可能會大幅增加，通過查看memory.max_usage_in_bytes，管理員可以提前預估這些服務在未來類似活動中的內存需求，為系統添加足夠的內存資源，確保系統在高并發情況下的穩定性。在異常診斷方面，當系統出現內存相關的問題時，對比當前內存使用量和歷史峰值內存使用量，可以幫助管理員快速判斷是否存在內存泄漏或者其他異常情況。如果當前內存使用量接近或超過歷史峰值，且持續上升，很可能存在內存泄漏問題，需要進一步排查和解決。通過 cgroup 跟蹤內存使用峰值，幫助進行資源規劃和異常診斷：

#!/bin/bash

# 確保以root權限運行
if [ "$(id -u)" -ne 0 ]; then
    echo "請使用root權限運行此腳本 (sudo)"
    exit 1
fi

# 配置監控參數
CGROUP_MOUNT="/sys/fs/cgroup/memory"
ECOMMERCE_GROUP="$CGROUP_MOUNT/ecommerce_service"
MONITOR_INTERVAL=2  # 監控間隔(秒)
DURATION=30         # 監控時長(秒)

# 清理殘留資源
cleanup() {
    # 終止監控進程
    if [ -n "$MONITORED_PID" ]; then
        kill $MONITORED_PID 2>/dev/null
        echo -e "\n已終止模擬服務進程"
    fi

    # 刪除控制組
    if [ -d "$ECOMMERCE_GROUP" ]; then
        rmdir $ECOMMERCE_GROUP
        echo "已刪除控制組"
    fi
}

# 確保cgroup已掛載
if ! mountpoint -q $CGROUP_MOUNT; then
    echo "掛載cgroup內存子系統..."
    mount -t cgroup -o memory memory $CGROUP_MOUNT || {
        echo "掛載失敗"
        exit 1
    }
fi

# 創建電商服務控制組
mkdir -p $ECOMMERCE_GROUP || {
    echo "創建控制組失敗"
    exit 1
}

# 設置內存限制（模擬促銷期間可能需要的內存）
echo "設置服務內存限制為1GB"
echo 1073741824 > $ECOMMERCE_GROUP/memory.limit_in_bytes  # 1GB

# 啟動模擬電商服務進程（會逐漸增加內存使用）
echo "啟動模擬電商服務進程..."
(
    # 模擬內存使用增長，模擬促銷期間的內存變化
    data=""
    while true; do
        # 每次循環增加內存使用
        data+=$(printf "x%.0s" {1..100000})  # 增加數據量
        sleep 1
    done
) &
MONITORED_PID=$!

# 將進程加入控制組
echo $MONITORED_PID > $ECOMMERCE_GROUP/cgroup.procs
echo "服務進程PID: $MONITORED_PID 已加入監控"

# 監控內存使用情況
echo -e "\n開始監控內存使用（持續$DURATION秒）..."
echo "時間(秒) | 當前使用(MB) | 峰值使用(MB)"
echo "----------------------------------------"

end_time=$((SECONDS + DURATION))
while [ $SECONDS -lt $end_time ]; do
    # 獲取當前內存使用量
    current=$(cat $ECOMMERCE_GROUP/memory.usage_in_bytes)
    # 獲取內存使用峰值
    peak=$(cat $ECOMMERCE_GROUP/memory.max_usage_in_bytes)

    # 轉換為MB
    current_mb=$((current / 1024 / 1024))
    peak_mb=$((peak / 1024 / 1024))

    # 顯示監控數據
    echo "$((SECONDS - (end_time - DURATION)))        | $current_mb          | $peak_mb"

    sleep $MONITOR_INTERVAL
done

# 分析結果
echo -e "\n=== 內存使用分析 ==="
current=$(cat $ECOMMERCE_GROUP/memory.usage_in_bytes)
peak=$(cat $ECOMMERCE_GROUP/memory.max_usage_in_bytes)
limit=$(cat $ECOMMERCE_GROUP/memory.limit_in_bytes)

current_mb=$((current / 1024 / 1024))
peak_mb=$((peak / 1024 / 1024))
limit_mb=$((limit / 1024 / 1024))

echo "內存限制: $limit_mb MB"
echo "最終內存使用: $current_mb MB"
echo "內存使用峰值: $peak_mb MB"

# 異常判斷邏輯
usage_ratio=$((peak * 100 / limit))
if [ $usage_ratio -gt 90 ]; then
    echo "警告: 內存使用峰值已超過限制的90%，系統可能面臨內存壓力"
elif [ $usage_ratio -gt 70 ]; then
    echo "提示: 內存使用峰值已超過限制的70%，建議關注資源使用情況"
fi

# 檢查是否存在內存泄漏跡象（當前使用接近峰值且持續增長）
if [ $current -gt $((peak * 95 / 100)) ]; then
    echo "警告: 當前內存使用接近歷史峰值，可能存在內存泄漏風險"
fi

# 清理資源
cleanup
echo -e "\n監控結束"

通過這個腳本，管理員可以：

觀察服務在高負載下的內存峰值，為未來促銷活動做資源規劃
及時發現內存使用異常（如接近限制或持續增長）
輔助判斷是否存在內存泄漏問題

腳本使用了 1GB 的內存限制作為示例，實際使用時可根據系統情況調整。監控間隔和時長也可以根據需要修改，以獲得更精確的內存使用數據。

3.2內存限制與 OOM 處理流程

（1）分配攔截機制：當進程向系統申請內存時，內核會立即啟動嚴格的檢查機制。內核會檢查memory.limit_in_bytes所設定的內存限制值，這個值就像是一道 “內存警戒線”，一旦進程申請的內存量加上當前已使用的內存量超過了這條警戒線，就會觸發__memcgroup_oom_kill函數。這個函數就像是一個 “內存警察”，專門負責處理內存超額的情況。

__memcgroup_oom_kill函數會在控制組內仔細選擇消耗內存最多的進程，將其作為 OOM（Out-Of-Memory）終止的目標。這就像是在一個班級里，如果資源不夠了，老師會先讓那些占用資源最多的學生 “讓出資源”，以保證整個班級（系統）的正常運轉。在實際的服務器環境中，可能會有多個進程同時運行在一個控制組內，當內存不足時，終止那些占用內存最多的進程，可以迅速釋放大量內存，避免整個系統因為內存耗盡而崩潰，保證其他重要進程能夠繼續運行。

（2）OOM 策略配置：內存 cgroup 允許用戶通過memory.oom_control 文件來靈活調整 OOM 處理策略。當memory.oom_control的值被設置為 0 時，默認啟用OOM Killer機制。在這種情況下，一旦內存使用超出限制，OOM Killer 就會按照前面提到的方式，果斷選擇并終止占用內存最多的進程，以恢復系統的內存平衡。這是一種比較激進的策略，雖然可能會導致某些進程的突然終止，但可以快速解決內存不足的問題，保證系統的穩定性。

而當memory.oom_control的值被設置為 1 時，OOM Killer 機制將被禁用。此時，如果進程遇到內存不足的情況，它不會被直接終止，而是會進入阻塞等待狀態，就像一個人在排隊等待資源，直到有足夠的內存可用或者超時。這種策略在一些對進程連續性要求較高的場景中非常有用，比如數據庫服務，不希望因為內存不足而突然終止進程，導致數據丟失或不一致。但是，這種策略也存在一定的風險，如果內存緊張的情況持續時間過長，可能會導致整個系統的性能下降，甚至出現死鎖等問題，因為多個進程都在等待內存資源，而內存資源又一直無法滿足它們的需求。

3.3層級化資源管理

（1）繼承與覆蓋規則：內存 cgroup 的層級化資源管理基于一套清晰的繼承與覆蓋規則。子控制組在創建時，會默認繼承父組的內存配置，這就像孩子會繼承父母的一些特征一樣。父組設置了內存使用的軟限制和硬限制，子控制組在沒有額外設置的情況下，會自動遵循這些限制。這種繼承機制大大簡化了資源管理的復雜度，對于一個擁有多個子系統的大型應用，只需要在父控制組中設置好整體的內存策略，各個子系統對應的子控制組就會自動遵循，確保整個應用的內存使用符合統一的規范。

不過，子控制組也具有一定的自主性，它可以根據自身的特殊需求，單獨設置更嚴格的內存限制。比如，在一個微服務架構中，某個微服務可能對內存的需求比較特殊，雖然父控制組為所有微服務設置了一個通用的內存上限，但這個微服務所在的子控制組可以進一步降低這個上限，以確保該微服務在內存使用上更加保守，避免因為內存使用不當而影響整個系統的穩定性。需要注意的是，子組內存上限絕對不得超過父組，這是層級化資源管理的一個基本原則，就像在一個公司中，部門的資源配額不能超過整個公司分配給它的總配額，否則會導致資源分配的混亂。通過這種繼承與覆蓋的規則，內存 cgroup 形成了一個清晰的樹狀資源配額體系，從根控制組開始，一層一層地向下傳遞和細化內存配置，實現了對系統內存資源的高效管理。

（2）跨層級統計：memory.use_hierarchy參數在內存 cgroup 的跨層級統計中起著關鍵作用，它就像是一個 “統計開關”，控制是否聚合子組內存使用量。當memory.use_hierarchy被設置為 1 時，系統會自動聚合子組的內存使用量，將其納入到父組的統計中。這在多級資源監控的場景中非常實用，比如在一個大型的 Kubernetes 集群中，集群可以看作是一個根控制組，下面包含多個節點，每個節點又可以看作是一個子控制組，節點上運行的容器則是更下一層的子控制組。通過啟用memory.use_hierarchy，管理員可以從集群層面快速了解整個集群的內存使用情況，包括各個節點以及節點上容器的內存使用總和，方便進行整體的資源評估和管理。

在容器編排系統中，通過查看聚合后的內存使用數據，管理員可以直觀地了解到整個集群的內存負載情況，判斷是否需要進行節點的擴容或縮容操作。如果發現某個節點的內存使用量過高，且已經接近或超過了其配額，可以考慮將部分容器遷移到其他內存資源較為充裕的節點上，以實現集群內存資源的均衡分配。而當memory.use_hierarchy被設置為 0 時，系統將只統計當前控制組自身的內存使用量，不包含子組的內存使用情況。這種設置在一些需要單獨關注某個控制組內存使用的場景中很有用，比如在調試某個特定的容器時，只關心這個容器自身的內存使用情況，而不希望受到其他容器的干擾。

四、內存 cgroup 與其他子系統的協同工作

4.1cgroup 與 CPU 子系統的資源協同

在復雜的系統環境中，內存 cgroup 很少單獨工作，它需要與其他子系統緊密協作，才能實現系統資源的高效利用和穩定運行。

內存限制常配合 CPU 配額（cpu.cfs_quota_us）使用，這在很多場景下都非常關鍵。以容器化微服務資源隔離為例，在一個容器集群中，每個微服務都以容器的形式運行，并且被分配到了不同的控制組中。通過設置memory.limit_in_bytes來限制每個容器的內存使用上限，同時配合cpu.cfs_quota_us來限制容器可以使用的 CPU 時間，這樣可以確保計算密集型任務在內存受限的同時不會占用過多 CPU 資源。假設一個數據分析微服務，它在處理大量數據時需要消耗較多的 CPU 資源，但如果沒有限制，它可能會把所有 CPU 資源都占用，導致其他微服務無法正常工作。通過設置合理的cpu.cfs_quota_us，比如每 100ms 周期內最多使用 50ms CPU 時間，就可以保證這個數據分析微服務在使用適量 CPU 資源的同時，不會影響其他微服務的正常運行。

通過 cpuset 子系統將內存控制組內的進程綁定到特定 CPU 核心 / 內存節點，是提升系統性能的重要手段。在多核心 CPU 和 NUMA（Non-Uniform Memory Access，非統一內存訪問）架構的系統中，不同 CPU 核心訪問內存的速度可能會有很大差異。將內存控制組內的進程綁定到特定 CPU 核心和內存節點，可以減少跨 NUMA 節點訪問延遲，提升數據局部性。例如，在一個大型數據庫系統中，將數據庫相關的進程綁定到特定的 CPU 核心和內存節點，這些進程在訪問內存時，可以直接訪問本地內存節點，而不需要跨節點訪問，大大提高了內存訪問速度，從而提升了數據庫系統的整體性能。在實際操作中，可以通過修改cpuset.cpus和cpuset.mems文件來實現進程的綁定。比如echo 0-3 > /sys/fs/cgroup/cpuset/myapp/cpuset.cpus表示將myapp控制組內的進程綁定到 CPU 核心 0 到 3 上，echo 0 > /sys/fs/cgroup/cpuset/myapp/cpuset.mems表示將進程綁定到內存節點 0 上。

cgroup 內存子系統與 CPU 子系統協同工作的示例如下：

#!/bin/bash

# 確保以root權限運行
if [ "$(id -u)" -ne 0 ]; then
    echo "請使用root權限運行此腳本 (sudo)"
    exit 1
fi

# 配置控制組路徑
CGROUP_BASE="/sys/fs/cgroup"
APP_GROUP="my_app_group"

# 各子系統控制組路徑
MEM_GROUP="$CGROUP_BASE/memory/$APP_GROUP"
CPU_GROUP="$CGROUP_BASE/cpu/$APP_GROUP"
CPUSET_GROUP="$CGROUP_BASE/cpuset/$APP_GROUP"

# 清理函數
cleanup() {
    # 終止測試進程
    if [ -n "$TEST_PID" ]; then
        kill $TEST_PID 2>/dev/null
        echo -e "\n已終止測試進程"
    fi

    # 刪除控制組
    if [ -d "$MEM_GROUP" ]; then
        rmdir $MEM_GROUP
    fi
    if [ -d "$CPU_GROUP" ]; then
        rmdir $CPU_GROUP
    fi
    if [ -d "$CPUSET_GROUP" ]; then
        rmdir $CPUSET_GROUP
    fi
    echo "已清理控制組資源"
}

# 檢查并掛載必要的cgroup子系統
mount_cgroups() {
    for subsys in memory cpu cpuset; do
        mount_point="$CGROUP_BASE/$subsys"
        if ! mountpoint -q $mount_point; then
            echo "掛載$subsys子系統到$mount_point..."
            mkdir -p $mount_point
            mount -t cgroup -o $subsys $subsys $mount_point || {
                echo "$subsys子系統掛載失敗"
                exit 1
            }
        fi
    done
}

# 創建控制組
create_cgroups() {
    echo "創建控制組..."
    mkdir -p $MEM_GROUP $CPU_GROUP $CPUSET_GROUP || {
        echo "創建控制組失敗"
        exit 1
    }
}

# 配置內存限制
configure_memory() {
    echo "配置內存限制為512MB..."
    echo 536870912 > $MEM_GROUP/memory.limit_in_bytes  # 512MB
}

# 配置CPU配額
configure_cpu() {
    echo "配置CPU配額：每100ms周期內最多使用50ms..."
    echo 100000 > $CPU_GROUP/cpu.cfs_period_us  # 周期100ms
    echo 50000 > $CPU_GROUP/cpu.cfs_quota_us     # 配額50ms
}

# 配置CPU和內存節點綁定
configure_cpuset() {
    # 獲取系統CPU核心數
    CPU_CORES=$(grep -c ^processor /proc/cpuinfo)
    MAX_CPU=$((CPU_CORES - 1))

    # 如果CPU核心數足夠，綁定到0-3核心，否則綁定到可用核心
    if [ $CPU_CORES -ge 4 ]; then
        CPU_LIST="0-3"
    else
        CPU_LIST="0-$MAX_CPU"
    fi

    echo "將進程綁定到CPU核心: $CPU_LIST"
    echo $CPU_LIST > $CPUSET_GROUP/cpuset.cpus

    # 綁定到內存節點0
    echo "將進程綁定到內存節點: 0"
    echo 0 > $CPUSET_GROUP/cpuset.mems

    # 繼承父控制組的任務文件
    echo "$(cat $CGROUP_BASE/cpuset/cpuset.tasks)" > $CPUSET_GROUP/cpuset.tasks
}

# 啟動測試進程
start_test_process() {
    echo -e "\n啟動CPU和內存密集型測試進程..."
    # 啟動一個同時消耗CPU和內存的進程
    (
        # 內存消耗部分
        data=""
        while true; do
            data+=$(printf "x%.0s" {1..100000})  # 增加內存使用
            # CPU消耗部分
            for ((i=0; i<10000000; i++)); do :; done  # 空循環消耗CPU
            sleep 0.1
        done
    ) &
    TEST_PID=$!
    echo "測試進程PID: $TEST_PID"

    # 將進程加入所有控制組
    echo $TEST_PID > $MEM_GROUP/cgroup.procs
    echo $TEST_PID > $CPU_GROUP/cgroup.procs
    echo $TEST_PID > $CPUSET_GROUP/cpuset.procs
    echo "進程已加入控制組"
}

# 顯示配置信息
show_configuration() {
    echo -e "\n=== 控制組配置信息 ==="
    echo "內存限制: $(cat $MEM_GROUP/memory.limit_in_bytes) 字節"
    echo "CPU周期: $(cat $CPU_GROUP/cpu.cfs_period_us) 微秒"
    echo "CPU配額: $(cat $CPU_GROUP/cpu.cfs_quota_us) 微秒"
    echo "綁定CPU核心: $(cat $CPUSET_GROUP/cpuset.cpus)"
    echo "綁定內存節點: $(cat $CPUSET_GROUP/cpuset.mems)"
    echo -e "\n按任意鍵停止測試并清理資源..."
}

# 主流程
mount_cgroups
create_cgroups
configure_memory
configure_cpu
configure_cpuset
start_test_process
show_configuration

# 等待用戶輸入后清理
read -n 1

# 清理資源
cleanup
echo "演示完成"

這個示例模擬了容器化環境中微服務的資源隔離場景，確保計算密集型任務在受限資源下運行，同時不會影響其他服務。在實際應用中，可以根據具體需求調整內存限制、CPU 配額和 CPU / 內存節點綁定配置。

4.2 cgroup 與設備子系統的隔離配合

在實際應用中，內存 cgroup 與設備子系統的協同工作也非常重要，特別是在一些對 IO 性能和資源隔離要求較高的場景中。

對于存儲密集型應用，如數據庫容器，同時配置 blkio 子系統（限制磁盤 IO）和內存 cgroup 是非常必要的。這類應用在運行過程中，會頻繁地進行磁盤讀寫操作，如果不對磁盤 IO 進行限制，可能會因為 IO 阻塞導致內存泄漏風險。通過設置 blkio 子系統的參數，如blkio.throttle.read_bps_device和blkio.throttle.write_bps_device，可以限制設備的讀寫帶寬。例如，設置echo "sda 10485760" > /sys/fs/cgroup/blkio/myapp/blkio.throttle.read_bps_device表示限制myapp控制組對sda設備的讀取帶寬為 10MB 每秒。同時，通過內存 cgroup 設置內存限制，如memory.limit_in_bytes，可以確保應用在內存使用上也受到嚴格控制，避免因為內存使用不當而導致系統性能下降或崩潰。這樣的聯合限制可以有效地避免因 IO 阻塞導致內存泄漏風險，保證數據庫容器的穩定運行。

devices 子系統在實現完整的容器資源隔離沙箱中發揮著關鍵作用。它可以限制控制組內進程訪問特定設備，與內存限制結合，為容器提供了全方位的資源隔離。在容器化環境中，每個容器都應該運行在一個相對獨立的沙箱中，不能隨意訪問宿主機的設備資源，否則可能會導致安全問題或資源沖突。通過 devices 子系統，可以精確地控制容器對設備的訪問權限。例如，設置echo 'a *:* rwm' > /sys/fs/cgroup/devices/myapp/devices.allow表示允許myapp控制組內的進程對所有設備進行讀寫操作，而設置echo 'c 1:3 rwm' > /sys/fs/cgroup/devices/myapp/devices.allow則表示只允許對字符設備 1:3 進行讀寫操作。配合內存 cgroup 的內存限制，如memory.limit_in_bytes，可以確保容器在內存使用和設備訪問上都受到嚴格控制，實現完整的容器資源隔離沙箱，提高系統的安全性和穩定性。

cgroup 內存子系統與設備子系統（blkio 和 devices）協同工作的示例如下：

#!/bin/bash

# 確保以root權限運行
if [ "$(id -u)" -ne 0 ]; then
    echo "請使用root權限運行此腳本 (sudo)"
    exit 1
fi

# 配置控制組路徑
CGROUP_BASE="/sys/fs/cgroup"
APP_GROUP="db_container"

# 各子系統控制組路徑
MEM_GROUP="$CGROUP_BASE/memory/$APP_GROUP"
BLKIO_GROUP="$CGROUP_BASE/blkio/$APP_GROUP"
DEVICES_GROUP="$CGROUP_BASE/devices/$APP_GROUP"

# 存儲設備（根據實際系統調整，這里使用sda作為示例）
STORAGE_DEVICE="sda"

# 清理函數
cleanup() {
    # 終止測試進程
    if [ -n "$TEST_PID" ]; then
        kill $TEST_PID 2>/dev/null
        echo -e "\n已終止測試進程"
    fi

    # 刪除控制組
    if [ -d "$MEM_GROUP" ]; then
        rmdir $MEM_GROUP
    fi
    if [ -d "$BLKIO_GROUP" ]; then
        rmdir $BLKIO_GROUP
    fi
    if [ -d "$DEVICES_GROUP" ]; then
        rmdir $DEVICES_GROUP
    fi
    echo "已清理控制組資源"
}

# 檢查并掛載必要的cgroup子系統
mount_cgroups() {
    for subsys in memory blkio devices; do
        mount_point="$CGROUP_BASE/$subsys"
        if ! mountpoint -q $mount_point; then
            echo "掛載$subsys子系統到$mount_point..."
            mkdir -p $mount_point
            mount -t cgroup -o $subsys $subsys $mount_point || {
                echo "$subsys子系統掛載失敗"
                exit 1
            }
        fi
    done
}

# 創建控制組
create_cgroups() {
    echo "創建控制組..."
    mkdir -p $MEM_GROUP $BLKIO_GROUP $DEVICES_GROUP || {
        echo "創建控制組失敗"
        exit 1
    }
}

# 配置內存限制
configure_memory() {
    echo "配置內存限制為1GB..."
    echo 1073741824 > $MEM_GROUP/memory.limit_in_bytes  # 1GB
}

# 配置blkio子系統（磁盤IO限制）
configure_blkio() {
    # 限制讀寫帶寬為10MB/s (10*1024*1024 = 10485760 bytes)
    echo "配置磁盤IO限制為10MB/s..."
    echo "$STORAGE_DEVICE 10485760" > $BLKIO_GROUP/blkio.throttle.read_bps_device
    echo "$STORAGE_DEVICE 10485760" > $BLKIO_GROUP/blkio.throttle.write_bps_device
}

# 配置devices子系統（設備訪問控制）
configure_devices() {
    echo "配置設備訪問權限..."

    # 默認拒絕所有設備訪問
    echo "a *:* rwm" > $DEVICES_GROUP/devices.deny

    # 允許訪問標準輸入輸出設備
    echo "c 1:3 rwm" > $DEVICES_GROUP/devices.allow  # /dev/null, /dev/zero等
    echo "c 1:5 rwm" > $DEVICES_GROUP/devices.allow  # /dev/tty

    # 允許訪問存儲設備（sda）
    echo "b 8:0 rwm" > $DEVICES_GROUP/devices.allow  # sda設備的主從設備號通常為8:0

    # 允許訪問臨時文件系統
    echo "c 1:7 rwm" > $DEVICES_GROUP/devices.allow  # /dev/full
    echo "c 1:8 rwm" > $DEVICES_GROUP/devices.allow  # /dev/random
    echo "c 1:9 rwm" > $DEVICES_GROUP/devices.allow  # /dev/urandom
}

# 啟動測試進程（模擬數據庫操作）
start_test_process() {
    echo -e "\n啟動模擬數據庫進程..."
    # 啟動一個同時消耗內存和磁盤IO的進程
    (
        # 創建測試文件
        TEST_FILE="/tmp/db_testfile.dat"

        # 模擬數據庫操作：循環讀寫文件并消耗內存
        data=""
        while true; do
            # 增加內存使用
            data+=$(printf "x%.0s" {1..100000})

            # 模擬磁盤IO操作
            dd if=/dev/zero of=$TEST_FILE bs=1M count=10 oflag=direct 2>/dev/null
            sync
            rm -f $TEST_FILE

            sleep 1
        done
    ) &
    TEST_PID=$!
    echo "測試進程PID: $TEST_PID"

    # 將進程加入所有控制組
    echo $TEST_PID > $MEM_GROUP/cgroup.procs
    echo $TEST_PID > $BLKIO_GROUP/cgroup.procs
    echo $TEST_PID > $DEVICES_GROUP/cgroup.procs
    echo "進程已加入控制組"
}

# 顯示配置信息
show_configuration() {
    echo -e "\n=== 控制組配置信息 ==="
    echo "內存限制: $(cat $MEM_GROUP/memory.limit_in_bytes) 字節"
    echo "磁盤讀帶寬限制: $(cat $BLKIO_GROUP/blkio.throttle.read_bps_device)"
    echo "磁盤寫帶寬限制: $(cat $BLKIO_GROUP/blkio.throttle.write_bps_device)"
    echo "允許訪問的設備: $(cat $DEVICES_GROUP/devices.allow)"
    echo -e "\n按任意鍵停止測試并清理資源..."
}

# 主流程
mount_cgroups
create_cgroups
configure_memory
configure_blkio
configure_devices
start_test_process
show_configuration

# 等待用戶輸入后清理
read -n 1

# 清理資源
cleanup
echo "演示完成"

這個示例特別適合模擬數據庫容器等存儲密集型應用的資源隔離場景，通過聯合配置避免因 IO 阻塞導致的內存問題，同時通過設備訪問控制實現完整的容器沙箱隔離。實際使用時，應根據系統的實際設備情況調整存儲設備參數和設備訪問權限配置。

五、實踐案例：容器場景下的內存 cgroup 應用

5.1容器環境：Docker/Kubernetes 資源管控

（1）Docker 配置映射

在 Docker 容器環境中，內存 Cgroup 扮演著至關重要的角色，它為容器提供了強大的內存管理能力。通過簡單的命令行參數，我們可以輕松地將內存限制和交換分區限制等配置，映射到內存 Cgroup 的對應參數上，實現對容器內存使用的精確控制。

當我們使用docker run -m 200M命令啟動一個容器時，實際上是在設置容器的內存限制。這個操作在內存 Cgroup 中對應的是memory.limit_in_bytes參數，200M 換算成字節為 209715200，即memory.limit_in_bytes=209715200。這意味著容器內所有進程的內存使用總和不能超過 200MB，一旦超過這個限制，系統會根據 OOM（Out-Of-Memory）機制采取相應措施，如觸發 OOM Killer 殺死容器內的進程，以釋放內存資源，保障容器和宿主機系統的穩定性。

對于交換分區限制，我們可以使用--memory-swap=300M參數。在內存 Cgroup 中，這對應著memory.memsw.limit_in_bytes參數，300M 換算后為 314572800，即memory.memsw.limit_in_bytes=314572800。這個參數限制了容器可以使用的內存和交換分區的總量，當容器的內存使用加上交換分區使用達到 300MB 時，同樣會觸發 OOM 機制。這一配置在容器需要大量內存但又要防止其過度占用系統資源時非常有用，例如在運行一些大數據處理任務的容器時，可以通過設置合理的交換分區限制，避免容器因過度使用交換分區而導致系統性能下降。

（2） Kubernetes QoS 分級

在 Kubernetes 集群環境中，內存 Cgroup 同樣是實現資源有效管理和 Pod 隔離的核心機制。Kubernetes 通過requests和limits聲明內存配額，底層則基于內存 Cgroup 實現 Pod 級別的內存隔離，這種機制對于保障關鍵業務的資源優先級至關重要。

當我們在 Kubernetes 的 Pod 配置文件中定義requests和limits時，例如：

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
    resources:
      requests:
        memory: "512Mi"
      limits:
        memory: "1Gi"

這里requests聲明了容器需要的最小內存資源，limits則設置了容器可使用的最大內存資源。Kubernetes 會根據這些聲明，在內存 Cgroup 中為 Pod 創建相應的配置，確保每個 Pod 只能在規定的內存范圍內運行。這種基于內存 Cgroup 的資源隔離機制，使得不同 Pod 之間的內存使用不會相互干擾。在一個同時運行著在線交易服務和后臺數據分析任務的 Kubernetes 集群中，在線交易服務的 Pod 可以設置較高的內存優先級，通過合理配置requests和limits，確保在高并發情況下，交易服務的 Pod 始終有足夠的內存可用，而不會因為數據分析任務 Pod 的內存使用波動而受到影響，從而保障了關鍵業務的穩定性和可靠性。

5.2微服務架構：防止內存泄漏擴散

在微服務架構的分布式系統中，內存泄漏是一個常見且棘手的問題。由于系統由多個獨立的微服務組成，每個微服務都可能在不同的進程或容器中運行，一旦某個微服務出現內存泄漏，它可能會逐漸耗盡所在節點的內存資源，進而影響同一節點上的其他微服務，甚至引發整個集群的故障。

一個電商系統的商品搜索微服務，如果存在內存泄漏問題，隨著時間的推移，它會不斷占用更多的內存。當內存使用達到一定程度時，可能會導致該節點上的其他微服務，如訂單處理微服務、用戶認證微服務等，因為內存不足而無法正常工作。這種級聯故障會嚴重影響系統的可用性和用戶體驗，導致訂單處理失敗、用戶無法登錄等問題。

為了解決這一問題，我們可以利用內存 Cgroup 為每個微服務實例創建獨立的 Cgroup 分組，并設置嚴格的內存限制。通過這種方式，將內存泄漏的影響范圍控制在單個微服務實例內，避免故障擴散到整個集群。

在 Go 語言編寫的微服務中，我們可以通過調用系統接口，結合內存 Cgroup 實現內存限制功能。以下是一個簡單的示例代碼，展示了如何為一個 Go 進程設置內存限制：

package main

import (
    "fmt"
    "os"
    "syscall"
)

func main() {
    // 創建一個新的Cgroup分組
    err := os.Mkdir("/sys/fs/cgroup/memory/my_service", 0755)
    if err != nil {
        fmt.Println("Failed to create cgroup:", err)
        return
    }
    defer os.Remove("/sys/fs/cgroup/memory/my_service")

    // 設置內存限制為100MB
    limit := int64(100 * 1024 * 1024)
    err = ioutil.WriteFile("/sys/fs/cgroup/memory/my_service/memory.limit_in_bytes", []byte(fmt.Sprintf("%d", limit)), 0644)
    if err != nil {
        fmt.Println("Failed to set memory limit:", err)
        return
    }

    // 將當前進程添加到Cgroup分組中
    pid := os.Getpid()
    err = ioutil.WriteFile("/sys/fs/cgroup/memory/my_service/cgroup.procs", []byte(fmt.Sprintf("%d", pid)), 0644)
    if err != nil {
        fmt.Println("Failed to add process to cgroup:", err)
        return
    }

    // 模擬內存申請
    var data []byte
    for {
        data = append(data, make([]byte, 1024*1024)...)
        fmt.Println("Memory allocated:", len(data)/1024/1024, "MB")
        // 休眠一段時間，避免進程瞬間耗盡內存
        time.Sleep(1 * time.Second)
    }
}

在這個示例中，我們首先創建了一個名為my_service的 Cgroup 分組，然后設置其內存限制為 100MB。接著，將當前進程的 PID 寫入cgroup.procs文件，使該進程受到內存限制的約束。當進程持續申請內存超過 100MB 的限制時，系統會觸發 OOM（Out-Of-Memory）機制，自動終止該進程，從而避免了內存泄漏問題擴散到其他微服務，保障了整個微服務架構的穩定性。

5.3多租戶系統：用戶級內存配額管理

在多租戶系統中，為不同租戶提供獨立的內存配額管理是確保系統資源公平分配和高效利用的關鍵。通過內存 Cgroup，我們可以實現這一目標，為每個租戶分配合理的內存資源，并對其使用情況進行監控和審計。

我們可以通過/sys/fs/cgroup/memory目錄下的配置文件，為每個租戶創建獨立的 Cgroup 分組，并設置相應的內存配額。在/sys/fs/cgroup/memory目錄下創建一個以租戶 ID 命名的子目錄，如/sys/fs/cgroup/memory/tenant1，然后在該目錄下設置memory.limit_in_bytes文件，指定租戶 1 的內存配額。假設我們為租戶 1 分配 512MB 的內存，那么可以執行以下命令：

echo $((512 * 1024 * 1024)) > /sys/fs/cgroup/memory/tenant1/memory.limit_in_bytes

這樣，租戶 1 下的所有進程的內存使用總和將被限制在 512MB 以內。

為了實現用戶組關聯分組，我們可以在/sys/fs/cgroup/memory目錄下創建用戶組目錄，如/sys/fs/cgroup/memory/group1，然后將屬于該用戶組的租戶目錄鏈接到用戶組目錄下。假設租戶 1 和租戶 2 屬于group1用戶組，我們可以執行以下命令：

ln -s /sys/fs/cgroup/memory/tenant1 /sys/fs/cgroup/memory/group1/tenant1
ln -s /sys/fs/cgroup/memory/tenant2 /sys/fs/cgroup/memory/group1/tenant2

通過這種方式，我們可以對用戶組進行統一的內存配額管理和監控。當某個租戶的內存使用超過配額時，系統會根據 OOM 機制進行處理，如終止該租戶下的部分進程，以釋放內存資源。同時，我們可以通過讀取memory.stat等文件，對每個租戶的內存使用情況進行詳細的統計和審計，實現 “超量使用自動限制，資源使用可審計” 的租戶隔離方案，確保多租戶系統的穩定性和公平性。

六、cgroup 版本演進與常見問題排查

6.1 v1 與 v2 版本差異

cgroup 歷經了 v1 和 v2 兩個主要版本的發展，每個版本都有其獨特的特性和適用場景，在內存管理等方面存在顯著差異。

特性	cgroup v1	cgroup v2
層級模型	多層級獨立子系統	單層級統一資源管理
內存統計粒度	進程組級	支持進程級與組級混合統計
OOM 機制	基于控制組整體	支持更精細的進程選擇策略
主流應用場景	Docker（默認）、傳統容器	Kubernetes（推薦）、云原生場景

cgroup v1 采用多層級獨立子系統的架構，每個資源子系統（如 CPU、內存、磁盤 I/O 等）都有自己獨立的層級結構。在這種架構下，一個進程可能在不同的子系統中屬于不同的控制組，這就導致了資源控制邏輯的復雜性增加，管理難度加大。例如，在管理一個應用的資源時，需要分別在 CPU 子系統、內存子系統等多個子系統中進行配置和管理，配置和管理的一致性難以保證。

而 cgroup v2 則進行了重大改進，采用單層級統一資源管理的架構，所有的資源子系統共享同一個層級結構。在 cgroup v2 中，每個進程只屬于一個控制組節點，這使得資源管理變得更加簡單和直觀。例如，在管理一個應用的資源時，只需要在同一個控制組節點中對所有資源進行統一配置和管理，大大降低了管理成本和出錯的概率。

在內存統計粒度方面，cgroup v1 主要是基于進程組級別的統計，對于進程級別的內存使用情況統計不夠精細。而 cgroup v2 則支持進程級與組級混合統計，這使得管理員可以更精確地了解每個進程的內存使用情況，為內存優化提供更詳細的數據支持。例如，在排查內存泄漏問題時，cgroup v2 可以更準確地定位到具體的進程，而 cgroup v1 則可能只能定位到進程組，難以進一步深入排查。

在 OOM 機制上，cgroup v1 是基于控制組整體來進行處理的，當控制組內的內存使用達到限制時，會觸發 OOM Killer 機制，選擇控制組內占用內存最多的進程進行終止。而 cgroup v2 支持更精細的進程選擇策略，它可以根據進程的重要性、內存使用模式等多個因素來綜合判斷，選擇最合適的進程進行處理，從而更好地保護關鍵業務進程，減少對業務的影響。例如，在一個包含多個微服務的 Kubernetes 集群中，cgroup v2 可以根據每個微服務的業務優先級，在內存不足時優先保護高優先級的微服務，避免其因 OOM 而中斷服務。

從主流應用場景來看，cgroup v1 由于其兼容性較好，目前仍然是 Docker 的默認選擇，在傳統容器場景中廣泛應用。而 cgroup v2 則在 Kubernetes 等云原生場景中表現出更好的適應性和擴展性，被推薦用于這些場景。例如，在 Kubernetes 中，cgroup v2 的統一層級結構和更精細的資源控制能力，使得它能夠更好地支持 Pod 的資源管理和調度，提高集群的資源利用率和穩定性。

6.2生產環境配置建議

在生產環境中，合理配置內存 cgroup 對于系統的穩定性和性能至關重要，以下是一些實用的配置建議。

禁用交換空間：通過執行echo 0 > memory.swappiness命令，可以將內存交換空間的使用比例設置為 0，從而避免內存限制被交換分區繞過。交換空間就像是內存不夠用時的 “備用倉庫”，但使用交換空間會帶來性能損耗，因為從磁盤讀寫數據比從內存讀寫數據要慢得多。在一些對性能要求極高的場景中，如實時交易系統、高性能計算集群等，禁用交換空間可以確保內存限制的嚴格生效，避免因為使用交換分區而導致系統性能下降，保證關鍵業務的高效運行。
設置軟限制：通過memory.soft_limit_in_bytes參數設置軟限制，允許進程在一定時間內臨時超額使用內存，這在很多場景下都非常有用。例如，在電商促銷活動期間，訂單處理服務可能會在短時間內接收大量訂單，導致內存使用量突然增加。通過設置軟限制，該服務可以在業務高峰期臨時使用更多內存，而不會因為內存限制而被 OOM Killer 終止。同時，軟限制需要配合memory.limit_in_bytes硬限制來使用，確保進程最終不會無限制地占用內存，保證系統的穩定性。
監控與告警：定期采集memory.usage_in_bytes和memory.failcnt等指標，結合 Prometheus 等監控工具，可以實現對內存使用情況的實時監控和異常預警。memory.usage_in_bytes反映了當前內存的使用量，通過監控這個指標，可以及時發現內存使用量的異常增長，提前采取措施進行優化。memory.failcnt記錄了內存分配失敗的次數，如果這個值不斷增加，說明系統可能存在內存不足的問題，需要進一步分析和解決。結合 Prometheus 的告警功能，可以在內存使用量接近限制或者內存分配失敗次數達到一定閾值時，及時發出告警通知，讓管理員能夠快速響應，避免系統出現故障。
版本兼容性：在一些系統中，如 CentOS 8 等，默認使用 cgroup v1，在使用過程中需要注意與 cgroup v2 子系統的掛載互斥問題。如果同時掛載 cgroup v1 和 cgroup v2 的內存子系統，可能會導致資源管理的混亂和沖突。在進行系統升級或者配置調整時，需要仔細評估應用對 cgroup 版本的兼容性，確保系統的正常運行。如果應用對 cgroup v2 有更好的支持，在滿足系統要求的情況下，可以考慮升級到支持 cgroup v2 的系統版本，以獲得更強大的資源管理能力。

6.3常見問題排查

（1）OOM 未觸發：當發現進程組內存使用超過限制，但 OOM（Out-Of-Memory）機制未觸發時，首先要檢查memory.limit_in_bytes是否正確設置。可以通過查看/sys/fs/cgroup/memory/your_group/memory.limit_in_bytes文件的內容，確認限制值是否符合預期。還要檢查oom_control是否被禁用。如果oom_control文件中的oom_kill_disable字段設置為 1，表示 OOM Killer 已被禁用。此時，需要將其設置為 0，以恢復 OOM Killer 的正常功能。可以通過執行echo 0 > /sys/fs/cgroup/memory/your_group/oom_control命令來啟用 OOM Killer。

#!/bin/bash

# 確保以root權限運行
if [ "$(id -u)" -ne 0 ]; then
    echo "錯誤: 請使用root權限運行此腳本 (sudo)"
    exit 1
fi

# 檢查是否提供了控制組名稱
if [ $# -ne 1 ]; then
    echo "用法: $0 <控制組名稱>"
    echo "示例: $0 my_app_group"
    exit 1
fi

CGROUP_NAME="$1"
CGROUP_BASE="/sys/fs/cgroup/memory"
CGROUP_PATH="$CGROUP_BASE/$CGROUP_NAME"

# 檢查控制組是否存在
if [ ! -d "$CGROUP_PATH" ]; then
    echo "錯誤: 控制組 $CGROUP_NAME 不存在于 $CGROUP_BASE"
    exit 1
fi

# 檢查內存限制設置
check_memory_limit() {
    echo -e "\n=== 內存限制檢查 ==="
    LIMIT_FILE="$CGROUP_PATH/memory.limit_in_bytes"

    if [ ! -f "$LIMIT_FILE" ]; then
        echo "錯誤: 無法找到內存限制文件 $LIMIT_FILE"
        return 1
    fi

    LIMIT=$(cat "$LIMIT_FILE")
    # 轉換為人類可讀格式
    if [ $LIMIT -eq $((-1)) ]; then
        LIMIT_HUMAN="無限制"
    else
        LIMIT_HUMAN=$(numfmt --to=iec --suffix=B $LIMIT)
    fi

    echo "當前內存限制: $LIMIT 字節 ($LIMIT_HUMAN)"

    # 檢查是否設置了合理的限制（不是無限制）
    if [ $LIMIT -eq $((-1)) ]; then
        echo "警告: 未設置內存限制，OOM機制不會觸發"
        return 1
    fi

    return 0
}

# 檢查當前內存使用情況
check_memory_usage() {
    echo -e "\n=== 內存使用檢查 ==="
    USAGE=$(cat "$CGROUP_PATH/memory.usage_in_bytes")
    PEAK=$(cat "$CGROUP_PATH/memory.max_usage_in_bytes")

    USAGE_HUMAN=$(numfmt --to=iec --suffix=B $USAGE)
    PEAK_HUMAN=$(numfmt --to=iec --suffix=B $PEAK)

    echo "當前內存使用: $USAGE 字節 ($USAGE_HUMAN)"
    echo "峰值內存使用: $PEAK 字節 ($PEAK_HUMAN)"

    # 與限制比較
    if [ $USAGE -ge $LIMIT ] && [ $LIMIT -ne $((-1)) ]; then
        echo "警告: 當前內存使用已超過限制"
    fi
}

# 檢查并修復OOM控制設置
check_oom_control() {
    echo -e "\n=== OOM機制檢查 ==="
    OOM_CONTROL="$CGROUP_PATH/oom_control"

    if [ ! -f "$OOM_CONTROL" ]; then
        echo "錯誤: 無法找到OOM控制文件 $OOM_CONTROL"
        return 1
    fi

    OOM_DISABLED=$(grep oom_kill_disable "$OOM_CONTROL" | awk '{print $2}')
    OOM_SCORE_ADJ=$(grep oom_score_adj "$OOM_CONTROL" | awk '{print $2}')

    echo "OOM Killer 狀態: $(if [ $OOM_DISABLED -eq 1 ]; then echo "已禁用"; else echo "已啟用"; fi)"
    echo "OOM 分數調整: $OOM_SCORE_ADJ"

    # 如果OOM被禁用，提供啟用選項
    if [ $OOM_DISABLED -eq 1 ]; then
        read -p "是否啟用OOM Killer? (y/n) " -n 1 -r
        echo
        if [[ $REPLY =~ ^[Yy]$ ]]; then
            echo "啟用OOM Killer..."
            echo 0 > "$OOM_CONTROL"

            # 驗證設置
            NEW_OOM_DISABLED=$(grep oom_kill_disable "$OOM_CONTROL" | awk '{print $2}')
            if [ $NEW_OOM_DISABLED -eq 0 ]; then
                echo "OOM Killer 已成功啟用"
            else
                echo "錯誤: 無法啟用OOM Killer"
                return 1
            fi
        fi
    fi

    return 0
}

# 顯示控制組中的進程
show_processes() {
    echo -e "\n=== 控制組中的進程 ==="
    PROCS_FILE="$CGROUP_PATH/cgroup.procs"

    if [ -s "$PROCS_FILE" ]; then
        echo "PID 列表:"
        cat "$PROCS_FILE"
        echo -e "\n進程詳情:"
        ps -p $(tr '\n' ',' < "$PROCS_FILE" | sed 's/,$//')
    else
        echo "控制組中沒有運行的進程"
    fi
}

# 主流程
echo "開始檢查控制組: $CGROUP_NAME"

check_memory_limit
check_memory_usage
check_oom_control
show_processes

echo -e "\n=== 檢查完成 ==="
echo "如果內存使用超過限制且OOM未觸發，可能的解決方案:"
echo "1. 確保內存限制設置正確（不是無限制）"
echo "2. 確保OOM Killer已啟用（oom_kill_disable=0）"
echo "3. 考慮調整內存限制值以適應應用需求"
echo "4. 檢查應用是否存在內存泄漏問題"

使用方法：

sudo ./cgroup_oom_check.sh 你的控制組名稱

腳本會引導你完成檢查過程，并在發現 OOM Killer 被禁用時提供啟用選項，幫助解決內存超限但 OOM 未觸發的問題。同時提供的診斷信息也能幫助你進一步分析系統內存使用情況。

（2）內存統計異常：如果遇到內存統計數據異常的情況，比如memory.stat中的某些指標與usage_in_bytes不一致，可能是因為內存統計中包含了內核態內存。可以通過對比memory.stat中的kmem相關指標，如memory.kmem.usage_in_bytes，來排查是否存在內核態內存泄漏或異常使用的問題。如果發現memory.kmem.usage_in_bytes持續增長且沒有合理的業務原因，可能需要進一步檢查內核模塊或驅動程序，看是否存在內存泄漏的情況，可以通過dmesg命令查看內核日志，尋找相關的錯誤信息。

#!/bin/bash

# 確保以root權限運行
if [ "$(id -u)" -ne 0 ]; then
    echo "錯誤: 請使用root權限運行此腳本 (sudo)"
    exit 1
fi

# 檢查是否提供了控制組名稱
if [ $# -ne 1 ]; then
    echo "用法: $0 <控制組名稱>"
    echo "示例: $0 my_app_group"
    exit 1
fi

CGROUP_NAME="$1"
CGROUP_BASE="/sys/fs/cgroup/memory"
CGROUP_PATH="$CGROUP_BASE/$CGROUP_NAME"

# 檢查控制組是否存在
if [ ! -d "$CGROUP_PATH" ]; then
    echo "錯誤: 控制組 $CGROUP_NAME 不存在于 $CGROUP_BASE"
    exit 1
fi

# 轉換字節為人類可讀格式
human_readable() {
    numfmt --to=iec --suffix=B $1
}

# 顯示主要內存統計數據
show_memory_stats() {
    echo -e "\n=== 主要內存統計數據 ==="

    # 基本內存使用
    USAGE=$(cat "$CGROUP_PATH/memory.usage_in_bytes")
    echo "memory.usage_in_bytes: $USAGE ($(human_readable $USAGE))"

    # 從stat文件獲取的總使用量
    STAT_TOTAL=$(grep total "$CGROUP_PATH/memory.stat" | awk '{print $2}')
    echo "memory.stat total: $STAT_TOTAL ($(human_readable $STAT_TOTAL))"

    # 對比差異
    DIFF=$(( USAGE > STAT_TOTAL ? USAGE - STAT_TOTAL : STAT_TOTAL - USAGE ))
    DIFF_PERCENT=$(( DIFF * 100 / (USAGE + 1) ))  # +1避免除零

    if [ $DIFF_PERCENT -gt 10 ]; then
        echo "警告: usage_in_bytes 與 stat total 差異較大 ($(human_readable $DIFF)，$DIFF_PERCENT%)"
    else
        echo "usage_in_bytes 與 stat total 差異在正常范圍內 ($(human_readable $DIFF)，$DIFF_PERCENT%)"
    fi
}

# 分析內核態內存使用
analyze_kmem_usage() {
    echo -e "\n=== 內核態內存使用分析 ==="

    # 內核態內存使用
    KMEM_USAGE=$(cat "$CGROUP_PATH/memory.kmem.usage_in_bytes")
    echo "內核態內存使用: $KMEM_USAGE ($(human_readable $KMEM_USAGE))"

    # 內核態內存限制
    KMEM_LIMIT=$(cat "$CGROUP_PATH/memory.kmem.limit_in_bytes")
    KMEM_LIMIT_HUMAN="無限制"
    if [ $KMEM_LIMIT -ne $((-1)) ]; then
        KMEM_LIMIT_HUMAN=$(human_readable $KMEM_LIMIT)
    fi
    echo "內核態內存限制: $KMEM_LIMIT ($KMEM_LIMIT_HUMAN)"

    # 從stat獲取的內核相關內存
    KMEM_STAT=$(grep kmem "$CGROUP_PATH/memory.stat" | awk '{sum += $2} END {print sum}')
    echo "memory.stat 中的內核內存總和: $KMEM_STAT ($(human_readable $KMEM_STAT))"

    # 檢查內核內存是否占比較高
    USAGE=$(cat "$CGROUP_PATH/memory.usage_in_bytes")
    if [ $USAGE -gt 0 ]; then
        KMEM_PERCENT=$(( KMEM_USAGE * 100 / USAGE ))
        echo "內核態內存占總內存比例: $KMEM_PERCENT%"

        if [ $KMEM_PERCENT -gt 30 ]; then
            echo "警告: 內核態內存占比超過30%，可能存在異常"
        fi
    fi
}

# 監控內核態內存變化
monitor_kmem_growth() {
    echo -e "\n=== 內核態內存增長監控 ==="
    echo "將監控30秒內的內核態內存變化 (每5秒一次)..."

    KMEM_VALUES=()
    for i in {1..7}; do
        CURRENT=$(cat "$CGROUP_PATH/memory.kmem.usage_in_bytes")
        KMEM_VALUES+=($CURRENT)
        echo "$(date +%H:%M:%S) - 內核態內存: $(human_readable $CURRENT)"
        if [ $i -lt 7 ]; then
            sleep 5
        fi
    done

    # 檢查是否持續增長
    GROWTH_COUNT=0
    for ((i=1; i<${#KMEM_VALUES[@]}; i++)); do
        if [ ${KMEM_VALUES[$i]} -gt ${KMEM_VALUES[$i-1]} ]; then
            GROWTH_COUNT=$((GROWTH_COUNT + 1))
        fi
    done

    if [ $GROWTH_COUNT -ge 5 ]; then
        echo "警告: 內核態內存在監控期間持續增長，可能存在內存泄漏"
    else
        echo "內核態內存在監控期間增長趨勢不明顯"
    fi
}

# 查看相關內核日志
check_kernel_logs() {
    echo -e "\n=== 內核日志檢查 ==="
    read -p "是否查看最近的內核日志以尋找內存相關錯誤? (y/n) " -n 1 -r
    echo

    if [[ $REPLY =~ ^[Yy]$ ]]; then
        echo -e "\n最近的內核日志 (內存相關):"
        dmesg | grep -iE 'out of memory|oom|memory leak|kmem|slab' | tail -20
        echo -e "\n如需查看完整日志，請運行: dmesg | less"
    fi
}

# 主流程
echo "開始檢查控制組內存統計: $CGROUP_NAME"

show_memory_stats
analyze_kmem_usage
monitor_kmem_growth
check_kernel_logs

echo -e "\n=== 檢查完成 ==="
echo "排查建議:"
echo "1. 如果內核態內存占比過高，檢查是否有異常的內核模塊或驅動"
echo "2. 若發現持續增長趨勢，使用dmesg和journalctl查看詳細內核日志"
echo "3. 考慮使用slabtop命令檢查內核slab分配情況"
echo "4. 檢查是否有應用程序頻繁使用內核資源(如大量系統調用、IO操作)"

使用方法：

sudo ./cgroup_memory_stat_check.sh 你的控制組名稱

腳本會幫助你判斷是否存在內核態內存異常使用的情況，并提供針對性的排查建議，特別適合解決 memory.stat 與 usage_in_bytes 不一致的問題。

（3）進程無法遷移：當嘗試將進程遷移到新的 Cgroup 分組時，如果出現無法遷移的問題，首先要確認目標分組路徑是否存在。可以通過執行ls /sys/fs/cgroup/memory/your_target_group命令，檢查目標分組目錄是否存在。還要確認當前用戶是否具備寫入cgroup.procs文件的權限。如果權限不足，可以通過修改文件權限或使用sudo命令來執行遷移操作。例如，sudo echo 1234 > /sys/fs/cgroup/memory/your_target_group/cgroup.procs，將 PID 為 1234 的進程遷移到目標分組中。

#!/bin/bash

# 確保以root權限運行
if [ "$(id -u)" -ne 0 ]; then
    echo "警告: 進程遷移可能需要root權限，建議使用sudo運行"
fi

# 檢查參數是否齊全
if [ $# -ne 3 ]; then
    echo "用法: $0 <源控制組> <目標控制組> <進程PID>"
    echo "示例: $0 old_group new_group 1234"
    exit 1
fi

SRC_GROUP="$1"
DEST_GROUP="$2"
PID="$3"
CGROUP_BASE="/sys/fs/cgroup/memory"

SRC_PATH="$CGROUP_BASE/$SRC_GROUP"
DEST_PATH="$CGROUP_BASE/$DEST_GROUP"
SRC_PROCS="$SRC_PATH/cgroup.procs"
DEST_PROCS="$DEST_PATH/cgroup.procs"

# 檢查進程是否存在
check_process() {
    if ! ps -p $PID > /dev/null; then
        echo "錯誤: 進程PID $PID 不存在"
        exit 1
    fi
    echo "確認: 進程 $PID 存在并正在運行"
}

# 檢查源控制組是否存在
check_source_group() {
    if [ ! -d "$SRC_PATH" ]; then
        echo "錯誤: 源控制組 $SRC_GROUP 不存在于 $CGROUP_BASE"
        exit 1
    fi

    if [ ! -f "$SRC_PROCS" ]; then
        echo "錯誤: 源控制組缺少cgroup.procs文件"
        exit 1
    fi

    # 檢查進程是否屬于源控制組
    if ! grep -q "^$PID$" "$SRC_PROCS"; then
        echo "警告: 進程 $PID 不在源控制組 $SRC_GROUP 中"
        read -p "是否繼續遷移操作? (y/n) " -n 1 -r
        echo
        if [[ ! $REPLY =~ ^[Yy]$ ]]; then
            exit 1
        fi
    else
        echo "確認: 進程 $PID 屬于源控制組 $SRC_GROUP"
    fi
}

# 檢查目標控制組是否存在
check_dest_group() {
    echo -e "\n=== 檢查目標控制組 ==="
    if [ ! -d "$DEST_PATH" ]; then
        echo "錯誤: 目標控制組 $DEST_GROUP 不存在"
        read -p "是否創建目標控制組 $DEST_GROUP? (y/n) " -n 1 -r
        echo
        if [[ $REPLY =~ ^[Yy]$ ]]; then
            mkdir -p "$DEST_PATH"
            if [ $? -ne 0 ]; then
                echo "錯誤: 無法創建目標控制組，可能權限不足"
                exit 1
            fi
            echo "已創建目標控制組: $DEST_PATH"
        else
            exit 1
        fi
    else
        echo "確認: 目標控制組 $DEST_GROUP 存在"
    fi

    if [ ! -f "$DEST_PROCS" ]; then
        echo "錯誤: 目標控制組缺少cgroup.procs文件"
        exit 1
    fi
}

# 檢查目標控制組權限
check_permissions() {
    echo -e "\n=== 檢查權限 ==="
    if [ ! -w "$DEST_PROCS" ]; then
        echo "警告: 當前用戶沒有寫入目標控制組cgroup.procs的權限"
        if [ "$(id -u)" -ne 0 ]; then
            echo "建議: 使用sudo提升權限后重試"
            exit 1
        else
            echo "錯誤: 即使作為root用戶也沒有寫入權限，檢查文件系統權限"
            exit 1
        fi
    fi
    echo "確認: 具備寫入目標控制組的權限"
}

# 執行遷移操作
migrate_process() {
    echo -e "\n=== 執行進程遷移 ==="
    echo "將進程 $PID 從 $SRC_GROUP 遷移到 $DEST_GROUP..."

    # 執行遷移命令
    echo $PID > "$DEST_PROCS"
    MIGRATE_EXIT_CODE=$?

    if [ $MIGRATE_EXIT_CODE -ne 0 ]; then
        echo "錯誤: 遷移操作失敗"
        # 嘗試使用替代方法
        echo "嘗試使用替代方法遷移..."
        sudo sh -c "echo $PID > $DEST_PROCS"
        if [ $? -ne 0 ]; then
            echo "錯誤: 即使使用sudo也無法完成遷移"
            exit 1
        fi
    fi
}

# 驗證遷移結果
verify_migration() {
    echo -e "\n=== 驗證遷移結果 ==="
    if grep -q "^$PID$" "$DEST_PROCS"; then
        echo "成功: 進程 $PID 已遷移到目標控制組 $DEST_GROUP"

        # 檢查是否已從源控制組移除
        if grep -q "^$PID$" "$SRC_PROCS"; then
            echo "注意: 進程仍存在于源控制組中，這在某些系統中是正常的"
        fi
    else
        echo "錯誤: 遷移未成功，進程不在目標控制組中"
        exit 1
    fi
}

# 主流程
echo "開始進程遷移檢查: $PID 從 $SRC_GROUP 到 $DEST_GROUP"

check_process
check_source_group
check_dest_group
check_permissions
migrate_process
verify_migration

echo -e "\n=== 操作完成 ==="
echo "進程遷移驗證通過"

使用方法：

# 基本用法
sudo ./cgroup_migrate_process.sh 源控制組 目標控制組 進程PID

# 示例
sudo ./cgroup_migrate_process.sh old_app_group new_app_group 1234

腳本會引導你完成整個遷移過程，并在出現問題時提供針對性的解決方案，特別適合解決 "無法遷移進程到新 cgroup" 的常見問題。

責任編輯：武曉燕來源：深度Linux