linux服务资源控制应通过systemd单元配置而非手动操作cgroups；CPU用CPUQuota硬限占比，内存须设MemoryMax防OOM，IO限速推荐IOReadBandwidthMax等直接带宽控制，并通过运行时指标验证生效。
Linux 服务资源控制的核心是 cgroups（v1 或 v2），现代发行版默认启用 cgroupsv2，且 systemd 已深度集成它来管理服务资源。直接操作 /sys/fs/cgroup 手动挂载或写值已不推荐；应通过 systemd 的单元配置项控制，既安全又持久。
systemd 服务单元的 CPU 限制怎么配
用 CPUQuota 最直观：它表示该服务能使用的 CPU 时间占比（相对于单个逻辑 CPU）。设为 50% 表示最多占用一个核的 50%，即 500ms/秒；设为 200% 则可跨两个核满负荷运行。
注意：CPUQuota 只在 CPUAccounting=yes 启用后才生效，且对突发负载压制明显——不是“平均分配”，而是硬性限频。
-
CPUQuota=30%：适合后台日志聚合类服务，防其吃满 CPU 影响主业务 - 搭配
CPUSchedulingPolicy=fifo和CPUSchedulingPriority=50可提升实时性，但仅适用于明确需要低延迟的场景（如音频处理），普通 Web 服务慎用 - 若服务频繁触发
Throttled（可通过systemctl show -p CPUAccounting,CPUSchedulingPolicy myapp.service查看），说明配额过紧，需调高或改用CPUWeight（cgroupsv2 下更平滑的相对权重机制）
内存限制为什么设置后服务仍被 OOM kill
根本原因常是没设 MemoryMax（cgroupsv2）或 MemoryLimit（cgroupsv1），而只设了 MemoryLow 或 MemorySoftLimit——后者只是“建议回收阈值”，不阻止超限。
OOM 发生时，内核会按 memory.oom.group 和进程的 oom_score_adj 综合判定杀谁。systemd 默认将服务进程的 oom_score_adj 设为 0，但若宿主机内存极度紧张，仍可能被杀。
- 必须显式设置
MemoryMax=512M（单位支持K/M/G）才能硬限内存 - 配合
MemorySwapMax=0禁用 swap，避免因交换加剧延迟 - 检查是否启用了
MemoryAccounting=yes，否则所有内存指标（如systemctl show -p MemoryCurrent）都为 0
IO 限速在哪些场景下实际有效
IOWeight（cgroupsv2）或 BlockIOWeight（cgroupsv1）只对使用 cfq 或 bfq IO 调度器的块设备有效；NVMe SSD 默认用 none 调度器，此时这些参数无效。
真正稳定的 IO 控制方式是 IOReadBandwidthMax / IOWriteBandwidthMax，它基于 cgroupsv2 的 io.max 接口，绕过调度器限制，直接控速。
- 对数据库备份脚本设
IOReadBandwidthMax=/dev/sdb 10M，可避免备份拖慢线上查询响应 - 注意路径必须是主设备（如
/dev/sdb），不能是分区（如/dev/sdb1），否则规则不生效 - 若用 LVM 或加密卷（如
/dev/mapper/vg-lv），需确认其底层物理设备并绑定对应限速规则
如何验证资源限制是否真实生效
别只信 systemctl show 输出的配置值——它只表示“已写入”，不代表内核已应用。要查运行时状态：
- 查当前内存用量：
systemctl show -p MemoryCurrent myapp.service（单位字节） - 查 CPU 节流次数：
cat /sys/fs/cgroup/myapp.service/cpu.stat | grep nr_throttled - 查 IO 限速是否触发：
cat /sys/fs/cgroup/myapp.service/io.stat | grep "throttle" - 最直接的方式是压测：用
stress-ng --cpu 4 --io 2 --vm 2 --vm-bytes 1G启动干扰进程，再观察目标服务的MemoryCurrent是否卡在MemoryMax附近、CPU 使用率是否被压到设定配额内
cgroupsv2 的统一层级结构让资源可见性变好，但 systemd 配置与内核 cgroup 接口之间存在缓存和延迟，重启服务后务必等待 2–3 秒再查状态，否则可能看到旧值。