Debian systemd资源限制

在Debian系统上，systemd通过cgroup v2为每个服务单元提供了精细的资源控制能力。当某个服务占用过多CPU或内存时，我们不需要借助第三方工具，直接修改单元文件中的资源限制参数就能生效。这些参数不是简单的开关，而是直接映射到Linux内核的cgroup控制器，理解它们的实际作用比记住参数名更重要。

CPU限制最常用的三个参数是CPUQuota、CPUWeight和AllowedCPUs。CPUQuota接受百分比值，例如200%表示允许使用两个完整的CPU核心。这个值不是上限，而是该服务在所有CPU核心上可消耗的总时间片比例。如果设置CPUQuota=50%，服务在多核系统上仍然可以跑满半个核心的计算能力。配置时直接在服务的[Service]段添加：

[Service]
CPUQuota=150%

CPUWeight则是相对权重，默认值是100。当系统CPU资源紧张时，权重高的服务会获得更多时间片。这个参数在系统空闲时不生效，只有发生争抢时才起作用。对于批处理任务可以设置较低权重，比如CPUWeight=10，保证交互式服务优先响应。AllowedCPUs用于绑定CPU核心，接受列表格式如0-3,7表示使用核心0到3以及核心7。这个参数对于NUMA架构的服务器特别有用，可以把网络密集型服务绑定到靠近网卡所在NUMA节点的核心上，减少跨节点内存访问延迟。

MemoryMax是设置内存硬限制的参数，单位可以是K、M、G等。当服务的内存使用量达到这个值，内核的OOM killer会在该cgroup内选择进程终止。注意这里触发的是cgroup级别的OOM，不是系统全局OOM。MemoryHigh则是软限制，达到后服务的内存分配会被节流，但不会立即被杀。这个设计允许服务在内存充足时超过软限制，只在系统内存紧张时回收。配置示例：

[Service]
MemoryMax=2G
MemoryHigh=1.5G

MemorySwapMax控制交换空间使用量，设为0可以完全禁止服务使用swap。对于延迟敏感的数据库服务，禁止swap能避免性能抖动，但也要确保物理内存足够。systemd还支持MemoryMin和MemoryLow，这两个参数在内存压力下保护关键服务。MemoryMin是硬性保证，即使系统内存极度紧张，这部分内存也不会被回收；MemoryLow是软性保证，尽量不回收但允许在极端情况下回收。合理使用这些参数可以构建分层的内存保护策略。

IO限制通过IOWeight、IOReadBandwidthMax和IOWriteBandwidthMax等参数实现。IOWeight类似于CPUWeight，默认100，影响IO调度器的权重分配。IOReadBandwidthMax和IOWriteBandwidthMax设置绝对带宽限制，单位可以是K、M、G等。对于日志服务或者备份服务，限制IO带宽可以防止它们占满存储总线的吞吐量。配置时需要注意设备路径的指定：

[Service]
IOReadBandwidthMax=/dev/sda 50M
IOWriteBandwidthMax=/dev/sda 30M

IO限制还可以细化到具体的IO操作类型。IOReadIOPSMax和IOWriteIOPSMax限制每秒操作次数，这对SSD存储更有意义，因为SSD的性能瓶颈往往在IOPS而非带宽。对于数据库的写前日志或者消息队列的持久化，限制IOPS比限制带宽更能精确控制对存储系统的影响。设备路径可以使用通配符，比如/dev/disk/by-uuid/来指定特定文件系统，避免设备名变化导致限制失效。

TasksMax限制服务可创建的进程和线程总数。默认情况下systemd已经设置了相对保守的值，但对于需要大量并发连接的服务，比如代理服务器或者WebSocket服务，默认值可能不够。这个参数直接控制cgroup的pids控制器，达到限制后fork系统调用会失败。配置方式很简单：

[Service]
TasksMax=4096

除了TasksMax，LimitNPROC也可以设置进程数限制，但这是通过rlimit机制实现的，与cgroup层面的限制是两套独立体系。建议优先使用TasksMax，因为它是cgroup原生的限制，不会受到ulimit继承关系的影响。对于容器化场景，TasksMax还能防止单个容器耗尽整个系统的进程表。

修改单元文件后执行systemctl daemon-reload再重启服务，新限制就会生效。但对于生产环境，重启服务可能不可接受。systemctl set-property命令可以动态调整正在运行服务的资源限制，无需重启。例如：

systemctl set-property nginx.service CPUQuota=200%
systemctl set-property nginx.service MemoryMax=4G

这些动态调整会立即生效，并且会持久化到/run/systemd/system/目录下的配置片段中。如果需要永久保留，可以创建/etc/systemd/system/服务名.service.d/override.conf文件。动态调整的能力让运维人员可以根据监控数据实时响应资源使用异常，不需要提前规划所有可能的限制值。调整后的值可以通过systemctl show 服务名来查看，确认是否生效。

配置完限制后，需要验证是否真正生效。systemd-cgtop命令可以实时查看各cgroup的资源使用情况，类似top命令但按服务分组。systemd-cgls以树状结构展示cgroup层级。更详细的检查可以使用cat /sys/fs/cgroup/system.slice/服务名.service/cpu.max等文件直接读取内核cgroup接口的值。对于CPU限制，cpu.max文件会显示配额和周期；对于内存限制，memory.max显示硬限制值，memory.high显示软限制值。如果这些文件内容与配置一致，说明限制已经正确应用到内核。

cat /sys/fs/cgroup/system.slice/nginx.service/cpu.max
cat /sys/fs/cgroup/system.slice/nginx.service/memory.max

压力测试是验证限制是否按预期工作的最好方式。使用stress-ng工具模拟CPU和内存负载，同时观察服务的资源使用是否被限制在配置值附近。对于IO限制，fio工具可以产生可控的IO负载。测试时要注意cgroup统计信息的更新延迟，通常几秒内的平均值才能反映真实限制效果。

一个常见错误是混淆CPUQuota的百分比含义。在多核系统上，100%只代表一个核心，如果服务需要两个核心应该设置200%。另一个陷阱是MemoryMax设置过低导致服务频繁触发OOM，而日志中可能没有明显错误，只有服务反复重启的记录。建议先通过监控观察服务的正常内存使用范围，再设置合理限制值。对于Java应用，堆内存设置和cgroup内存限制的交互也容易出问题。较新版本的OpenJDK会自动识别cgroup限制并调整堆大小，但旧版本可能读取的是宿主机内存信息，导致在容器或cgroup限制下分配过多堆内存而触发OOM。

IO限制中设备路径的指定也容易出错。如果使用/dev/sda这样的设备名，在系统重启后可能变化。建议使用/dev/disk/by-uuid/或/dev/disk/by-path/下的持久化路径。另外，IO限制只对直接IO和经过文件系统的缓冲IO生效，对于绕过文件系统的原始设备访问，限制行为可能不同。在配置IO限制前，先确认服务的IO模式。

在实际生产系统中，资源限制不应该孤立配置，而应该形成分层策略。系统关键服务如sshd、systemd-journald设置MemoryMin保证基本内存，设置较高CPUWeight保证响应速度。业务服务根据优先级分档，核心业务设置CPUWeight=200，批处理任务设置CPUWeight=50。对于多租户环境，可以在用户slice层面设置总资源限制，然后让各个服务在slice限制内竞争。systemd支持在slice单元中设置资源限制，所有属于该slice的服务共享这些限制。这种层级结构让资源管理更加清晰，避免单个服务配置遗漏导致整体资源失控。

# /etc/systemd/system/user-1000.slice
[Slice]
MemoryMax=8G
CPUQuota=400%

systemd资源限制的强大之处在于它与Linux内核cgroup的深度集成，所有限制都在内核层面执行，性能开销极低。掌握这些参数后，Debian系统上的服务资源管理就不再依赖外部工具，配置即文档，systemd单元文件本身就是资源策略的可执行描述。