Linux服务器cgroups v2资源隔离配置与容器资源限制实战

cgroups v2架构演进与服务器运维价值

服务器运维中，资源隔离是保障多租户环境和混合负载稳定运行的核心能力。cgroups v2自Linux内核4.5引入、5.x逐步完善后已成为主流发行版默认方案。与v1相比，v2采用统一层级结构（unified hierarchy），所有控制器挂在同一个cgroup树下，解决了v1中多层级混乱导致的资源分配不一致问题。云服务器选型时，底层cgroups版本直接影响容器密度和资源利用率上限。

物理机架设场景中，cgroups v2配合systemd可以精确控制每个服务的CPU、内存、IO份额，避免单一服务异常消耗全部资源导致整机雪崩。IDC数据中心内，这一能力是算力资源规划的基础。

cgroups v2核心文件系统结构解析

v2的cgroup文件系统挂载在/sys/fs/cgroup，结构为单层级树形：

/sys/fs/cgroup/
├── cgroup.controllers        # 可用控制器列表
├── cgroup.max.descendants    # 最大子cgroup数
├── cgroup.max.depth          # 最大层级深度
├── cpu.max                   # CPU带宽限制
├── cpu.weight                # CPU权重分配
├── memory.max                # 内存硬限制
├── memory.current            # 当前内存使用
├── memory.swap.max           # swap限制
├── io.max                    # IO带宽限制
└── user.slice/               # 用户服务cgroup
    └── user-1000.slice/

关键变化：v2中cpu.max替代了v1的cpu.cfs_quota_us和cpu.cfs_period_us，格式为"max 100000"或"50000 100000"，分别表示不限配额和50%CPU配额。cpu.weight替代了cpu.shares，取值1-10000，默认100。

CPU资源隔离配置与权重分配实战

场景：一台32核物理机上同时运行API服务和批处理任务，API服务需要优先保障响应延迟，批处理任务可以低优先级占用空闲CPU。

通过systemd配置资源隔离（推荐方式），创建service文件：

# /etc/systemd/system/api-service.service
[Unit]
Description=API Service
After=network.target

[Service]
Type=simple
ExecStart=/opt/api/start.sh
# CPU权重：API服务获得更高优先级
CPUWeight=300
# 内存限制：最多8GB
MemoryMax=8G
MemorySwapMax=0
# IO权重
IOWeight=200

[Install]
WantedBy=multi-user.target

# /etc/systemd/system/batch-job.service
[Unit]
Description=Batch Processing Job

[Service]
Type=simple
ExecStart=/opt/batch/run.sh
CPUWeight=50
MemoryMax=4G
MemorySwapMax=2G
IOWeight=50

权重分配比例300:50意味着API服务在资源竞争时获得约85.7%的CPU时间，批处理任务获得14.3%。空闲时批处理任务仍可使用全部CPU，仅在竞争时按权重分配。

内存与swap限制配置与故障排查

内存限制是服务器安全加固的关键环节。OOM Killer在cgroup层级工作，当进程超过memory.max时触发cgroup内OOM，不会影响其他cgroup中的服务。

手动配置cgroup内存限制：

# 创建子cgroup
mkdir /sys/fs/cgroup/api-service
cd /sys/fs/cgroup/api-service

# 启用内存控制器
echo "+memory" > /sys/fs/cgroup/cgroup.subtree_control

# 设置8GB硬限制
echo "8589934592" > memory.max
# 禁用swap
echo "0" > memory.swap.max

# 将进程加入cgroup
echo "12345 12346" > cgroup.procs

故障排查命令：

# 查看cgroup内存使用
cat /sys/fs/cgroup/api-service/memory.current
# 查看OOM事件统计
cat /sys/fs/cgroup/api-service/memory.events
# 查看哪些进程在cgroup内
cat /sys/fs/cgroup/api-service/cgroup.procs

memory.events中oom_kill计数器非零表示该cgroup曾触发OOM Kill，需要排查是内存泄漏还是配额不足。high计数器表示触发内存压力回收的次数。

IO带宽限制与高可用集群场景配置

高可用集群中，磁盘IO争抢是常见瓶颈。cgroups v2的IO控制器支持按设备限制读写带宽：

# 限制sda设备读带宽100MB/s，写带宽50MB/s
echo "8:0 rbps=104857600 wbps=52428800" > io.max

设备号8:0对应/dev/sda，通过lsblk或stat -c "0x%t" /dev/sda获取主设备号。

Docker容器资源限制本质上是cgroups v2配置的封装：

docker run -d \
    --name api-container \
    --cpu-weight=300 \
    --memory=8g \
    --memory-swap=8g \
    --io-weight=200 \
    api-service:latest

通过docker inspect可以看到容器cgroup路径：/sys/fs/cgroup/system.slice/docker-<container-id>.scope。

硬件性能测评中的cgroups监控工具链

实时监控cgroup资源使用，systemd-cgtop是最直接的工具：

systemd-cgtop
# 输出示例：
# Control Group            Tasks   %CPU   Memory  Input/s  Output/s
# api-service.scope         12     45.2   6.2G    120M/s   80M/s
# batch-job.scope           4      12.1   3.1G    200M/s   150M/s

对于需要持久化记录的场景，cadvisor + Prometheus方案可以采集cgroup指标并长期存储。cadvisor默认暴露/metrics端点，包含container_cpu_usage_seconds_total、container_memory_working_set_bytes等核心指标。

服务器故障排查中，cgroup事件日志是重要线索。通过journalctl -u api-service结合memory.events可以快速定位OOM触发时间点和资源变化趋势，配合告警体系实现主动防御。