从systemd-cgtop到自定义Slice：深入掌握Linux cgroups实战指南

在容器化技术席卷全球的今天，Docker和Kubernetes已成为开发者日常工作的标配。但你是否好奇过，这些容器是如何实现资源隔离的？答案就藏在Linux内核的cgroups技术中。本文将带你从两个实用工具systemd-cgtop和systemd-cgls入手，逐步深入cgroups的世界，最终实现自定义资源隔离环境的构建。

1. 初识cgroups：容器技术的基石

cgroups（control groups）是Linux内核提供的一种机制，用于限制、记录和隔离进程组所使用的物理资源。它最早由Google工程师在2006年提出，并于2007年合并到Linux 2.6.24内核中。

cgroups的核心功能：

• 资源限制：可以限制进程组使用的CPU、内存、磁盘I/O等资源
• 优先级分配：可以设置不同进程组使用资源的权重
• 资源统计：监控进程组的资源使用情况
• 进程控制：可以冻结、恢复进程组

现代容器技术（如Docker）正是基于cgroups和namespace等技术实现的资源隔离。理解cgroups的工作原理，对于深入掌握容器技术至关重要。

2. 可视化监控：systemd-cgtop与systemd-cgls实战

在systemd管理的Linux系统中，有两个非常实用的工具可以帮助我们直观地观察cgroups的运行情况。

2.1 systemd-cgtop：资源监控利器

systemd-cgtop类似于我们熟悉的top命令，但它展示的是各个cgroup的资源使用情况：

$ systemd-cgtop
Path                                Tasks   %CPU   Memory  Input/s Output/s
/                                   231     0.9    692.2M  -       -
/system.slice/ModemManager.service   1       -      -      -       -
/system.slice/vmware.service         8       -      -      -       -
/user.slice/user-1000.slice          7       -      -      -       -

各列含义：

• Path：cgroup的路径
• Tasks：该cgroup中的进程数
• %CPU：CPU使用率
• Memory：内存使用量
• Input/s和Output/s：I/O活动状态

2.2 systemd-cgls：层级结构查看器

systemd-cgls则用于展示cgroups的层级结构：

$ systemd-cgls /system.slice
/system.slice:
├─sshd.service
│ └─10796 /usr/sbin/sshd -D
├─docker.service
│ ├─1234 /usr/bin/dockerd -H fd://
│ └─5678 docker-containerd --config /var/run/docker/containerd/containerd.toml
└─nginx.service
  └─9012 nginx: master process /usr/sbin/nginx

这个命令清晰地展示了各个服务在cgroup树中的位置，以及它们包含的进程。

3. 创建自定义Slice：实战资源隔离

理解了cgroups的基本概念和监控方法后，我们可以开始创建自定义的Slice来实现资源隔离。

3.1 Slice单元基础

在systemd中，Slice是一种特殊的单元类型，用于创建cgroup层级结构。默认情况下，systemd创建了三个Slice：

1. system.slice：系统服务
2. user.slice：用户会话
3. machine.slice：虚拟机

我们可以创建自定义的Slice来管理特定应用或服务的资源。

3.2 创建Web服务Slice示例

假设我们需要为Web服务创建一个独立的资源池，限制其CPU和内存使用：

1. 创建/etc/systemd/system/web.slice文件：

[Unit]
Description=Web Service Slice

[Slice]
CPUAccounting=true
MemoryAccounting=true
CPUShares=512
MemoryLimit=1G

2. 让服务使用这个Slice。创建/etc/systemd/system/nginx.service.d/slice.conf：

[Service]
Slice=web.slice

3. 重新加载systemd配置并重启服务：

sudo systemctl daemon-reload
sudo systemctl restart nginx

3.3 验证Slice效果

使用systemd-cgtop查看资源使用情况：

$ systemd-cgtop
Path                Tasks   %CPU   Memory  Input/s Output/s
/web.slice          5       25.3   512.4M  -       -
/system.slice       45      12.1   1.2G    -       -

可以看到，nginx服务现在运行在web.slice中，其资源使用受到了我们设置的限制。

4. 高级资源控制：多服务资源分配策略

在实际生产环境中，我们经常需要为多个服务分配不同的资源权重。下面通过一个例子展示如何实现。

4.1 创建业务Slice

假设我们有两个服务：api.service和batch.service，我们希望API服务能获得更多的CPU资源。

1. 创建基础Slice/etc/systemd/system/business.slice：

[Unit]
Description=Business Applications Slice

[Slice]
CPUAccounting=true
MemoryAccounting=true

2. 为API服务创建配置/etc/systemd/system/api.service.d/resource.conf：

[Service]
Slice=business.slice
CPUShares=1024
MemoryLimit=2G

3. 为批处理服务创建配置/etc/systemd/system/batch.service.d/resource.conf：

[Service]
Slice=business.slice
CPUShares=512
MemoryLimit=1G

这样配置后，当系统CPU资源紧张时，API服务将获得比批处理服务多一倍的CPU时间。

4.2 资源限制参数详解

常用的资源限制参数包括：

参数	描述	示例值
CPUShares	CPU相对权重	1024
MemoryLimit	内存硬限制	1G
MemoryHigh	内存软限制	800M
IOWeight	块设备I/O权重	100
CPUQuota	CPU时间配额	50%

重要提示：修改Slice或服务配置后，需要执行以下命令使更改生效：

sudo systemctl daemon-reload
sudo systemctl restart [服务名]

5. cgroups与容器技术的关联

现代容器技术如Docker底层正是使用了cgroups来实现资源隔离。理解了我们手动配置Slice的过程，就能更好地理解Docker的资源限制参数。

5.1 Docker资源限制参数对应关系

Docker参数	对应的cgroups设置
--cpus	cpu.cfs_quota_us
--memory	memory.limit_in_bytes
--cpu-shares	cpu.shares
--blkio-weight	blkio.weight

5.2 手动Slice vs Docker容器

通过手动创建Slice实现的资源隔离，与Docker容器的主要区别在于：

1. 隔离粒度：

   • Docker：完整的文件系统、网络、进程等隔离
   • 手动Slice：仅资源限制，无其他隔离

2. 管理复杂度：

   • Docker：简单易用的命令行接口
   • 手动Slice：需要直接编辑systemd单元文件

3. 可移植性：

   • Docker：镜像可跨环境移植
   • 手动Slice：配置绑定到特定主机

在实际工作中，对于需要完整隔离的环境，Docker仍是更好的选择。但对于一些传统服务或特殊场景，手动配置Slice提供了更精细的控制能力。

6. 性能调优实战案例

让我们通过一个实际案例，展示如何使用cgroups解决资源争用问题。

6.1 问题场景

假设我们有一个服务器运行着：

• 关键业务API服务（api.service）
• 数据批处理服务（batch.service）
• 定时报告生成服务（report.service）

在业务高峰期，批处理服务占用了大量CPU资源，导致API响应变慢。

6.2 解决方案

1. 创建优先级Slice结构：

/etc/systemd/system/
├── critical.slice
├── normal.slice
└── lowpri.slice

2. 配置各Slice的资源限制：

critical.slice：

[Slice]
CPUAccounting=true
CPUShares=2048

normal.slice：

[Slice]
CPUAccounting=true
CPUShares=1024

lowpri.slice：

[Slice]
CPUAccounting=true
CPUShares=512

3. 将服务分配到适当的Slice：

• API服务 → critical.slice
• 批处理服务 → normal.slice
• 报告服务 → lowpri.slice

6.3 效果验证

使用systemd-cgtop观察资源分配：

$ systemd-cgtop
Path                    Tasks   %CPU   Memory
/critical.slice/api     8       65.2   1.2G
/normal.slice/batch     4       25.1   2.4G
/lowpri.slice/report    2       9.7    512M

可以看到，关键API服务获得了最多的CPU资源，确保了业务高峰期的稳定性。

7. 常见问题与排查技巧

在实际使用cgroups时，可能会遇到各种问题。下面分享一些常见问题的解决方法。

7.1 资源限制未生效

症状：设置了MemoryLimit但服务仍能使用更多内存。

可能原因：

1. 未启用MemoryAccounting
2. 服务未重启
3. systemd未重新加载配置

解决方法：

# 确认Slice配置中包含
MemoryAccounting=true

# 重新加载并重启服务
sudo systemctl daemon-reload
sudo systemctl restart [服务名]

7.2 CPU限制异常

症状：设置了CPUShares但CPU分配不符合预期。

排查步骤：

1. 检查cgroup层级结构：

   systemd-cgls
   

2. 确认服务确实运行在正确的Slice中
3. 检查是否有父cgroup设置了更严格的限制

7.3 实用调试命令

1. 查看特定cgroup的详细配置：

   cat /sys/fs/cgroup/memory/your.slice/memory.limit_in_bytes
   

2. 实时监控cgroup的CPU使用：

   systemd-cgtop -c cpu
   

3. 检查服务当前的cgroup设置：

   systemctl show [服务名] -p ControlGroup
   

掌握这些工具和技巧，能够帮助您更高效地排查cgroups相关的问题。