通过CPUQuota和IORead/WriteBandwidthMax可在systemd服务单元中精准限制CPU与I/O带宽，如CPUQuota=40%、IOReadBandwidthMax=/dev/sda 15M，配合systemctl edit、daemon-reload及systemd-cgtop等工具验证生效。

直接在服务单元文件里加几行配置，就能有效约束服务对 CPU 和 I/O 带宽的占用，防止它拖垮整台机器。核心不是“堵死”，而是“划清边界”——让一个服务失控时，影响范围可控。

CPU 使用限制：用 CPUQuota 精准节流

CPUQuota 是最常用、最直观的 CPU 限流方式，它按百分比分配 CPU 时间片，基于 cgroups v2 的 cpu.max 实现，不依赖进程优先级，效果稳定。

• CPUQuota=30% 表示该服务最多使用 1 个逻辑 CPU 核心的 30%（即平均 0.3 核），即使系统空闲，它也无法突破这个硬上限
• 若服务是多线程且跑在 4 核机器上，想让它最多占满 1.5 核，可设为 CPUQuota=150%
• 避免设为 CPUQuota=100%：这等于不限制（默认行为），真正起作用的是低于 100% 的值
• 不推荐用 CPUShares：它只设相对权重，在 CPU 繁忙时才生效，无法防止单服务长期霸占资源

I/O 带宽限制：用 IOReadBandwidthMax 和 IOWriteBandwidthMax

带宽限制针对磁盘读写速率，适用于日志密集型、缓存刷盘或备份类服务，防止 I/O 打满导致其他服务响应卡顿。

• IOReadBandwidthMax=/dev/sda 20M 限制该服务从系统盘 sda 每秒最多读取 20MB
• IOWriteBandwidthMax=/dev/sdb 10M 限制向数据盘 sdb 每秒最多写入 10MB
• 支持多个设备分别设限，例如同时限制系统盘和 NVMe 盘
• 注意：需确认内核启用 io controller（cgroups v2 下通常默认开启），可通过 cat /proc/cgroups | grep io 验证

配置与生效流程（以 redis.service 为例）

推荐用 systemctl edit 创建覆盖配置，不改动原始文件，便于升级维护：

• 运行 sudo systemctl edit redis.service
• 输入以下内容：

  [Service]
  CPUQuota=40%
  IOReadBandwidthMax=/dev/sda 15M
  IOWriteBandwidthMax=/dev/sda 8M

• 保存退出后执行 sudo systemctl daemon-reload
• 重启服务：sudo systemctl restart redis

验证是否真正起效

配置完别跳过验证，否则可能限过头导致服务异常，或根本没生效：

• 查当前设置：systemctl show redis.service | grep -E "(CPUQuota|IO.*Bandwidth)"
• 实时观察 I/O 压力：systemd-cgtop -P（按 P 切换显示 I/O bandwidth）
• 查看 cgroup 底层值：cat /sys/fs/cgroup/system.slice/redis.service/io.max（输出应含你设的设备与速率）
• 压测时用 iostat -x 1 对比 /dev/sda 的 %util 和 rMB/s，确认未超设定带宽