Linux 临时服务资源限制：CPUQuota、MemoryMax 与命令行验收

排查一台 Linux 机器上的临时任务时，最怕的是“参数写进去了，但进程根本没有受到预期约束”。用 systemd-run 启动 transient unit，可以把一次性的命令放进独立 cgroup，再用 systemctl status 和属性查询确认限制是否生效。下面做一个可删除的小实验：给任务设置 CPUQuota=50% 和 MemoryMax=256M，最后核对实际单元状态。

先让临时服务跑起来，再确认它属于哪个单元

先准备一个不会修改系统数据的短任务。这里用 sleep 让单元保持几秒，便于在它退出前观察属性；生产任务替换成自己的命令即可。

systemd-run --unit=demo-limit.service --collect sleep 30
systemctl status demo-limit.service --no-pager
systemctl show demo-limit.service -p Id -p ControlGroup -p ActiveState

第一行返回后，systemd-run 已经把命令交给临时单元；第二行应能看到 Active: active (running)，第三行会给出单元 ID、cgroup 路径和运行状态。若状态已变成 inactive，先把任务时间调长再查，别把“任务结束”误判为“没有创建单元”。

为什么要保留 unit 名称

直接后台运行一条命令时，进程树和启动脚本容易混在一起；固定的 demo-limit.service 让查询、审计和清理都有明确对象。--collect 会在单元结束后回收 transient unit 的运行记录，实验完成后不会留下长期服务。

CPUQuota 与 MemoryMax 分别限制什么

资源参数可以在启动时传给 transient unit。下面的命令让任务使用最多一个 CPU 的 50%，并把该单元的内存硬上限设为 256M：

systemd-run --unit=demo-limit.service --collect \
  -p CPUQuota=50% \
  -p MemoryMax=256M \
  sleep 30

systemctl show demo-limit.service \
  -p CPUQuotaPerSecUSec -p MemoryMax -p EffectiveMemoryMax

CPUQuota=50% 不是“整台机器只能用 50% CPU”，而是以单个 CPU 的总时间为基准计算额度；多核机器上若要允许两个 CPU 的总额度，才会出现超过 100% 的设置，这就是 CPU上限 的含义。MemoryMax=256M 则是绝对内存限制，实际生效值还可能受到父 slice 更严格的限制，所以验收时同时看 EffectiveMemoryMax 更稳妥，这个值就是内存上限的最终边界。

把限制写入启动链，避免只在终端里做一次实验

如果这是定时任务或部署脚本的一部分，建议把参数和命令放在同一段可审查的启动链里，并给单元加上描述：

systemd-run --unit=report-limit.service \
  --description="daily report resource limit" \
  --collect \
  -p CPUQuota=50% \
  -p MemoryMax=256M \
  /usr/local/bin/report-job --date 2026-08-30

执行后立即用 systemctl show report-limit.service -p Description -p CPUQuotaPerSecUSec -p EffectiveMemoryMax 复核，而不是只相信脚本返回 0。对长期服务，更适合把同样的属性放到正式 unit 的 [Service] 段并走正常发布流程；临时单元适合一次性作业、灰度验证和故障复现。

常见坑：能启动不代表限制真的适用

没有权限时该怎么判断

用户级 manager 与系统级 manager 的可用资源控制能力不同。如果返回权限错误或属性为空，先确认当前命令是在用户 manager 还是系统 manager 下运行，并检查主机是否启用了对应的 cgroup 控制器；不要用“加大参数”掩盖环境不支持。

MemoryMax 到底是不是温和的告警

它是硬上限，不是只记录超标事件的告警开关。接近上限的作业应先用 MemoryHigh 做压力控制，再把 MemoryMax 留作最后防线，并为被终止的任务准备重试或补偿路径。

为什么查不到刚才的服务

使用了 --collect 后，任务退出时单元会被回收；要观察结果，就在任务运行期间查询，或先去掉 --collect 做一次可审计实验。临时单元结束后，命令的退出码仍可通过作业日志保留。

验收清单

• 启动返回成功，并能在运行窗口内看到 Active: active (running)。
• systemctl show 能读到 CPUQuotaPerSecUSec 和 MemoryMax。
• EffectiveMemoryMax 与父级约束一致，没有被更严格的 slice 静默覆盖。
• 任务结束后确认退出码、日志和临时单元清理结果。

相关问答

CPUQuota=50% 能固定占用半个核心吗？

它表达的是 CPU 时间额度，不保证进程始终获得连续的半个核心；调度、竞争和 quota 周期都会影响瞬时表现。

MemoryMax=256M 超过后一定立刻杀进程吗？

达到不可容纳的内存状态时，cgroup 内的 OOM 处理可能终止其中的进程；应结合任务日志与退出状态确认，不要把它当成业务级重试机制。

临时单元适合替代所有服务配置吗？

不适合。一次性任务和灰度验证适合 systemd-run，长期服务仍应使用版本化 unit 文件，便于审查、回滚和开机管理。

小结

这次实验的关键不在于记住两条参数，而是把“启动命令—临时单元—cgroup 属性—运行结果”串起来。先用 systemd-run 建立明确对象，再用 systemctl show 读取有效值，资源限制才算完成了一次可复核的配置。