systemd-run 怎样给临时任务设置内存上限

临时批处理、数据转换或维护命令如果直接在当前 Shell 中运行，内存失控时很容易影响同一台机器上的其他任务。用 systemd-run 创建一个 transient service，再通过 --property=MemoryMax=... 写入单元属性，就能把内存上限绑定到这一次任务，不必先创建长期存在的 service 文件。

官方地址：https://www.freedesktop.org/software/systemd/man/latest/systemd-run.html

最小写法是 systemd-run --property=MemoryMax=512M --wait --collect ./batch-job --input data.ndjson。MemoryMax=512M 是临时单元的内存上限；--wait 等命令结束，--collect 让已结束的 transient unit 自动回收。需要排查结果时，先换成 --remain-after-exit，不要一开始就自动清理。

MemoryMax 到底限制了什么

systemd-run 的默认形态是创建一个临时服务单元，让后面的命令作为该单元的主进程运行。--property=MemoryMax=512M 等价于给这个单元设置 MemoryMax=512M，因此限制的对象是该单元的控制组内存，而不是当前登录 Shell 的全部进程。

MemoryMax 更接近“不能越过的上限”，不是“达到某个值后主动降速”。如果任务需要先受到回收压力、但不希望立刻进入强限制，应另外研究 MemoryHigh 等资源控制属性；不要把两者当作同一个开关。

用一条命令给临时任务设置上限

把资源属性放在命令主体之前，读者看到命令时就能区分“systemd-run 的选项”和“被启动程序的参数”。下面给任务起一个稳定的临时单元名，方便后续查日志和属性。

# 给一次性导入任务设置 512 MiB 内存上限，并等待任务退出
systemd-run \
  --unit=ndjson-import-once \
  --property=MemoryMax=512M \
  --wait \
  --collect \
  /opt/tools/import-ndjson --input /srv/data/events.ndjson

这里的 --property 可以重复使用，也可以一次传入多个单元属性。512M 是便于阅读的容量单位；生产环境应根据任务峰值、机器余量和同机服务的资源预算选择，不要把示例数值直接当成通用推荐。

为什么有时要用 --remain-after-exit

--collect 适合“执行完就不留临时单元”的批处理，但排查内存限制时，自动回收会让你失去一部分查看窗口。改用 --remain-after-exit，transient unit 在命令退出后仍保留为已结束状态，便于用 systemctl show 读取单元属性和结果。

# 调试阶段保留已结束的临时单元，便于查看属性和结果
systemd-run \
  --unit=ndjson-import-debug \
  --property=MemoryMax=512M \
  --remain-after-exit \
  /opt/tools/import-ndjson --input /srv/data/events.ndjson

# 确认该单元记住的资源属性与主进程结果
systemctl show ndjson-import-debug \
  -p MemoryMax -p MemoryCurrent -p Result -p ExecMainStatus

三种选项的取舍可以这样记：--wait 关注调用方是否等待命令结束，--remain-after-exit 关注结束后是否保留单元记录，--collect 关注结束后是否自动清理 transient unit。它们不是互斥的概念，真正组合时要以当前 systemd 版本支持的命令行为为准。

怎样判断是内存限制还是程序自身失败

只看到 systemd-run 创建成功，不能说明业务命令成功。至少要把单元结果、主进程退出状态和日志分开看。观察阶段先不要使用 --collect，否则单元可能已被清理。

# 查看单元结果、退出码和当前内存字段
systemctl show ndjson-import-debug \
  -p ActiveState -p SubState -p Result -p ExecMainCode -p ExecMainStatus \
  -p MemoryCurrent -p MemoryMax

# 只读取这一个临时单元的日志，避免把系统其他服务混在一起
journalctl -u ndjson-import-debug --no-pager

Result、ExecMainStatus 和日志要结合起来解释：命令返回非零、参数错误、输入文件失败与资源限制不是同一个原因。不要只凭一次退出码就断言发生了 OOM；应先确认单元的资源属性和日志是否指向内存压力。

单位、权限和清理边界

最容易忽略的是单位。MemoryMax=512M 是带单位的容量写法，和无单位的整数含义不同；脚本里最好始终显式写出 K、M 或 G，降低复查成本。

如果当前用户没有创建系统级 transient service 的权限，可以先明确任务要运行在用户级 systemd 还是系统级 systemd，再考虑 --user、权限授权和资源控制器是否可用。不要为了绕过权限把命令改成高权限执行，权限边界本身就是排查条件。

调试完成后，如果使用了 --remain-after-exit，应按环境的清理策略停止并移除这类临时单元；一次性正式任务则优先使用 --wait --collect，让生命周期和日志留存策略保持一致。

一张表记住选择

常见问题

MemoryMax 会限制当前 Shell 吗？

不会把当前 Shell 中所有无关进程一起纳入；它针对由 systemd-run 创建的临时单元及其控制组。命令启动的子进程是否同属该单元，要按具体启动方式和 systemd 的单元边界判断。

为什么设置了 MemoryMax 还要看日志？

因为单元创建成功、程序正常退出、程序返回错误和资源压力是不同层次的状态。systemctl show 负责看属性与退出状态，journalctl 负责看该单元的日志上下文，两者缺一不可。

什么时候应该写正式 service 文件？

如果任务需要长期启停、依赖关系、重启策略、固定账号和审计配置，建议转为正式 unit 文件。systemd-run 更适合临时批处理、人工维护和一次性复查。

总结一下：把 MemoryMax 当成 transient service 的资源边界，把 --wait 当成调用方等待选择，把 --remain-after-exit 和 --collect 当成状态保留与自动清理选择；排障时再用 systemctl show 和 journalctl 把资源属性、退出结果和日志对应起来。