凌晨三点监控平台弹出一条告警某台业务主机的内存使用率异常冲到 98%Nginx 开始大面积 503。登录上去一查元凶是装在那台机器上的采集agent——正常情况下它只占几十MB内存偏偏那天晚上上游队列积压agent 的批量处理逻辑一口气把积压数据全翻进内存两个小时内存从 80MB 涨到 3.5GB把同机柜的所有业务进程都拖进内存回收风暴。那次事故之后我给自己定了一条规矩凡是跑在宿主机上的 agent 类进程资源上限必须在系统层兜住而不是指望业务代码自觉。现在我最顺手、也最推荐的做法就是 systemd cgroups v2。这篇文章把完整的配置、验证和踩坑过程写下来包括怎么确认系统真的在用 cgroups v2、unit 文件里每个限制字段的含义、怎么验证限额真的生效以及一堆看起来生效其实没有的坑。适合所有需要在宿主机上跑采集、同步、上报、备份这类后台 agent 的运维和开发同学。1. 为什么我坚持在系统层管 agent 的资源1.1 代码里限内存为什么总失败不少人第一反应是在 agent 代码里做内存保护比如定时检查占用、超过阈值就降级。这个思路我不能说错但它有几个天生短板。agent 不一定是你自己写的。生产环境里大量 agent 是第三方的监控上报客户端、日志转发器、数据库备份工具、云厂商的元数据采集程序。你根本改不了它们的代码更别提在合适的位置埋内存保护逻辑。就算是自己维护的 agent内存到底什么时候超也很难在业务层精确判断。语言运行时、JIT、第三方缓存库、mmap 映射文件、线程栈哪个环节多吃一口你都不能完全掌控。你按 1GB 写死保护阈值它可能在 900MB 时已经触发 GC 风暴也可能在 1.2GB 时才刚把缓存写满你的保护逻辑要么误伤要么漏掉。还有一层agent 往往会拉起子进程。比如采集程序调 shell 脚本、起子命令做数据预处理业务代码只能管理自己的进程管不住整个进程树。子进程吃内存业务层是看不见的。有人会想到 ulimit。ulimit 确实能限制单进程的虚拟内存但它对 mmap 大块内存、线程栈的行为在不同语言运行时下表现不一致容易误伤而且它只管单个进程限制不了 CPU 占比更管不了 IO。最关键的是agent 可能是被别的管理器拉起来的你在启动脚本里写的 ulimit 不一定被继承今天能拦住明天换启动方式就失效了。结论就一句话资源限制这种事放在业务层太脆弱放在内核层才靠谱。1.2 systemd cgroups v2比单点限制更完整的那道闸systemd 在你机器上是 1 号进程所有以 unit 方式运行的服务天然落在它管理的 cgroup 树里。cgroup 是内核的机制它限制和统计的对象不是单个进程而是一组进程——不管 agent fork 多少子进程、开多少线程只要进了同一个 cgroup就都在同一本账上谁也逃不掉。cgroups v2 相比 v1 最大的变化是把原来散落在多个挂载点的控制器统一进一棵层级树。v1 时代memory、cpu、io 各挂各的挂载点一个进程要同时受多个控制器管理父子关系不清晰想安全的委派子 cgroup 都很麻烦。v2 全部收敛到 /sys/fs/cgroup 这一棵树里控制器按需在子树开启父子继承关系简单明确。systemd 从很早的版本就开始适配 v2现在主流发行版上服务单元的资源限制直接映射到 cgroup v2 的对应文件——MemoryHigh 写进 memory.highCPUQuota 写进 cpu.max清晰得很。这套方案还有两个隐性好处一是 unit 文件是文本可以进配置管理仓库换机器复制就能用二是 systemd 自带重启策略限制触发导致进程被杀后可以按 Restart 自动拉起业务侧基本无感。对于 agent 这种挂了就挂了吧拉起来继续跑的进程这套组合拳是最省心的。2. 开工前体检确认 cgroups v2 真在跑2.1 三行命令确认当前版本别急着写配置先确认你的内核和 systemd 到底在用什么。一条命令看 cgroup 文件系统类型stat -fc %T /sys/fs/cgroup/如果输出是cgroup2fs说明系统已经跑在 cgroups v2 上如果输出是tmpfs那就是 cgroups v1目录下会分散挂着 memory、cpu、cpuset 这些子目录。再看一眼控制器和 systemd 版本cat /sys/fs/cgroup/cgroup.controllers systemd --versioncgroup.controllers列出当前层级可用的控制器常见的有 cpu、memory、io、pids。systemd 版本虽然一般不会太低但如果你要玩 OOMPolicy 这类新特性最好确认一下版本号相关功能要 systemd 247 以上才支持。2.2 还在 v1 的话怎么安全切到 v2如果你的发行版还在默认跑 v1可以通过内核启动参数切过去。通用的做法是改 GRUB 配置在GRUB_CMDLINE_LINUX里加一个参数systemd.unified_cgroup_hierarchy1改完执行 update-grub部分发行版是 grub2-mkconfig重启后就是 v2 了。注意这是个环境级的切换机器上的容器运行时、Java 应用这些对 cgroup 敏感的组件都要跟着适配别在生产机直接一把梭。我建议先在测试机验证重启后/sys/fs/cgroup变成单一层级老的/sys/fs/cgroup/memory那些 v1 接口消失systemd 各 slice 正常起来再推到生产。改内核参数这种事务必先确认你还有带外管理通道云主机的 VNC/串口防止参数写错进不了系统这种教训我见过太多次了。2.3 控制器与 subtree_control限额生效的前提条件v2 里有个很容易被忽略的概念控制器在某个层级上是否启用取决于 cgroup.subtree_control 文件里的声明。你可以在 /sys/fs/cgroup 下看到这棵树但真正决定我的 unit 能用 memory 限制吗的是 system.slice 这一层的 subtree_controlcat /sys/fs/cgroup/cgroup.subtree_control cat /sys/fs/cgroup/system.slice/cgroup.subtree_control正常情况下你会看到cpu memory io pids这些关键字。systemd 在开机时会把需要的控制器写进子树的 subtree_control所以一般不用手动干预。但如果你的内核引导参数里出现过cgroup_disablememory之类的东西memory 控制器可能根本没进来你写 MemoryMax 也白写。这块check一下后面能省不少排查时间。v2 还有一个没有内部进程的规则一个 cgroup 要么直接运行进程要么只当容器装着子 cgroup两者不能同时做。systemd 在底层帮你处理了这件事——每个 unit 都有自己独立的叶子 cgroup 跑进程所以从使用者的角度看基本无感。但如果你的 agent 自己要管理嵌套 cgroup后面讲 Delegate 时会提到这条规则就很重要了。3. 一套可直接抄的 unit把 agent 关进资源笼子3.1 先看完整配置下面这个示例是一个典型的采集 agent启动后常驻内存周期性扫目录、打日志、偶尔跑个子命令。我把它所有的资源限制都写进 unit作为标准模板# /etc/systemd/system/collect-agent.service [Unit] DescriptionData Collect Agent Afternetwork-online.target Wantsnetwork-online.target [Service] Typesimple ExecStart/opt/collect-agent/bin/collect-agent --config /etc/collect-agent/config.toml Restarton-failure RestartSec3 TimeoutStopSec30 # --- 内存 --- MemoryHigh400M MemoryMax600M MemorySwapMax0 # --- CPU --- CPUQuota150% CPUWeight20 # --- 进程/线程数 --- TasksMax256 # --- IO --- IOWeight10 IOReadBandwidthMax/dev/sda 100M IOWriteBandwidthMax/dev/sda 50M # --- OOM 时的行为 --- OOMPolicystop # --- 顺手做点安全加固 --- NoNewPrivilegestrue PrivateTmptrue ProtectSystemstrict ProtectHomeread-only [Install] WantedBymulti-user.target字段不一定每个都要但内存、CPU、Tasks 这三样是 agent 场景的底线。下面逐个拆开说。3.2 内存两道闸MemoryHigh 与 MemoryMax 怎么配合MemoryHigh 和 MemoryMax 是 cgroup v2 内存控制器里最核心的两个文件systemd 直接对应暴露成两个字段。它们的区别可以用水杯来记MemoryHigh 是高水位线MemoryMax 是杯沿。超过 MemoryHigh 之后内核会开始对这个 cgroup 施加回收压力优先回收 page cache、让分配内存的路径变慢、进程可能出现卡顿但不会立刻杀进程。这是给 agent 的警告区间让它在被处以极刑之前先自行收敛。超过 MemoryMax 之后就是硬性上限。内核尝试回收失败直接在 cgroup 内挑一个坏进程杀掉通常是内存分配最猛的那个然后报 OOM。对应到 systemd 日志里你会看到 Memory cgroup out of memory: Killed process。两个字段怎么配我给一个经验值先估算 agent 正常高峰时的内存比如 300MB那么 MemoryHigh 设 400M给一点缓冲MemoryMax 设 600M留出容许它短暂疯一下但绝不能把宿主机拖死的空间。High 和 Max 之间的距离就是 agent 的容错区间——内核会在这个区间里不断回收而不是一过线就杀。距离太小稍微波动就 OOM触发频繁重启距离太大等于没限制。另外强烈建议把 MemorySwapMax0 一起写上。原因我在第 5 章会展开简单说就是不限制 swapMemoryMax 就只是半扇门。如果 agent 本身很关键不想它在系统内存紧张时被疯狂回收还可以用 MemoryMin 给它一个最低保护额度意思是系统再缺内存这个 cgroup 里的数据也尽量保留。不过这是另一套逻辑agent 场景一般用不上知道有这回事就行。3.3 CPU 配额别把 CPUQuota 的百分比理解错CPUQuota100% 的意思是最多吃满一个 CPU 核心不是所有 CPU 总能力的 100%。在一台 32 核机器上100% 依然只是一个核的算力。想让它用 1.5 个核就写 150%想完全锁死在一个核内就写 100%。它对应内核的 cpu.max 文件格式是配额/周期默认周期是 100ms所以 150% 在文件里看到的是150000 100000单位是微秒。这个理解错了配额就会设大或设小完全不是你以为的效果。CPUQuota 是硬隔离适合不管机器多闲agent 都不能抢超过多少 CPU的场景。另一个字段 CPUWeight 是相对权重只在 CPU 争抢时才起作用默认 100范围 1-10000。把 agent 的 CPUWeight 设成 20意思是同一台机器上一旦业务进程和它抢 CPUagent 分到的比例会明显低于业务进程。实际使用中我的习惯是CPU 用 Quota 做硬隔离IO 用 Weight 做软优先这样 agent 不会因为某个瞬间的文件扫描把主业务的 IO 带宽吃光。3.4 线程数、IO 与顺手加固TasksMax256 映射到 pids.max限制的是这个 cgroup 里进程加线程的总数。agent 类程序最容易翻车的一个点就是线程泄漏某个库的线程池反复创建不回收肉眼看似没异常实际上 pids.current 悄悄涨破几百上千。有了 TasksMax这类问题会在早期显形而不是等到整台机器的 PID 耗尽。IO 限制对采集类 agent 特别有用。IOWeight10 让 agent 的磁盘 IO 请求在竞争中低人一等如果你知道它会疯狂写某个盘或者读某个盘可以直接用 IOReadBandwidthMax、IOWriteBandwidthMax 设绝对带宽。注意这里语法是设备节点路径 数值比如 /dev/sda而不是任意目录路径。安全加固字段是我顺手加的习惯。NoNewPrivilegestrue 禁止进程通过 exec 提升权限PrivateTmptrue 给 agent 独立的 /tmpProtectSystemstrict 把整个文件系统改为只读除了几个显式的可写路径。对采集 agent 来说它根本不需要写系统目录这些限制基本不会影响功能但能大大缩小它被攻破后的破坏半径。3.5 加载配置的正确动作改完 unit 文件动作序列是固定的systemd-analyze verify /etc/systemd/system/collect-agent.service systemctl daemon-reload systemctl enable --now collect-agent systemctl status collect-agentsystemd-analyze verify会检查 unit 语法和字段合法性配置有低级错误可以提前暴露。daemon-reload 必须做systemd 不会自动感知 unit 文件变化这也是新手最容易犯的错——改完直接 restart发现配置没生效其实压根没 reload。4. 限额有没有生效从 systemctl 到 cgroup 文件全链路验证4.1 systemctl status 和 systemd-cgtop 能告诉我们什么配完之后不要只看进程好像还活着要确认限制真的挂上了。先看 statussystemctl status collect-agent现代 systemd 的输出会自动带上资源统计类似这样● collect-agent.service - Data Collect Agent Loaded: loaded (/etc/systemd/system/collect-agent.service; enabled; preset: enabled) Active: active (running) since Fri 2025-01-10 10:00:00 CST; 3h 5min ago Main PID: 12345 (collect-agent) Tasks: 18 (limit: 256) CPU: 3min 12.5s Memory: 132.1M (limit: 600.0M)如果这里没显示 Tasks / CPU / Memory 这几行说明对应控制器的 accounting 没开。你写了 MemoryMax、TasksMax、CPUQuota 这些限制字段systemd 一般会自动打开对应的 accounting如果你只想监控不限制就得显式写 MemoryAccountingyes、CPUAccountingyes。systemd-cgtop是另一个好用的实时工具效果类似 top但按 cgroup 聚合展示。跑起来能看到每个 unit 的 CPU 使用率、内存、IO 和 PID 数agent 的异常增长在这里一眼就能看出来。4.2 直接读 cgroup 文件眼见为实systemd 只是把限制写进了内核的 cgroup 文件真正执行限制的是内核。所以最硬核的验证是直接读 v2 的接口文件路径在/sys/fs/cgroup/system.slice/collect-agent.service/下cat /sys/fs/cgroup/system.slice/collect-agent.service/memory.max cat /sys/fs/cgroup/system.slice/collect-agent.service/memory.high cat /sys/fs/cgroup/system.slice/collect-agent.service/memory.current cat /sys/fs/cgroup/system.slice/collect-agent.service/memory.events cat /sys/fs/cgroup/system.slice/collect-agent.service/cpu.max cat /sys/fs/cgroup/system.slice/collect-agent.service/cpu.stat cat /sys/fs/cgroup/system.slice/collect-agent.service/pids.current cat /sys/fs/cgroup/system.slice/collect-agent.service/pids.max对照关系如下systemd 字段cgroup v2 文件含义MemoryHighmemory.high软上限超了被回收MemoryMaxmemory.max硬上限超了 OOMMemorySwapMaxmemory.swap.max该 cgroup 的 swap 上限CPUQuotacpu.max配额/周期的微秒数CPUWeightcpu.weightCPU 相对权重TasksMaxpids.max进程 线程上限IOWeightio.weightIO 相对权重这里有个小技巧memory.events是诊断神器它记录了 low、high、max、oom、oom_kill 这几类事件的累计次数。如果 agent 白天运行正常、夜里偶尔卡顿看这个文件就能知道是内存撞到 high 被持续回收还是真的触发了 OOM。4.3 用压力测试把 OOM 和 CPU 节流逼出来配置写完了最好真的把 agent 逼到墙角一次确认限制触发路径是通的。我习惯用 systemd-run 起一个临时单元来测试不污染正式服务。比如测内存systemd-run --unitmemtest -p MemoryMax200M python3 -c import time; buf[] while True: buf.append(bytearray(10*1024*1024)); time.sleep(0.5)这个 Python 脚本每 0.5 秒分配 10MB跑到 200MB 左右必然撞上限。观察cat /sys/fs/cgroup/system.slice/memtest.service/memory.events你会看到oom_kill 1的计数日志里也能找到内核的 kill 记录。agent 生产环境不方便这么折腾但至少在一台测试机上验证一次整套链路我心里才踏实。CPU 节流验证类似。没有 stress-ng 的话用几个死循环也能凑合systemd-run --unitcpuload -p CPUQuota100% bash -c for i in {1..4}; do ( while :; do :; done ) done; sleep 10四个死循环本来能吃满 4 个核但 CPUQuota100% 把它们限死在一个核的算力内。等结束后看 cpu.statcat /sys/fs/cgroup/system.slice/cpuload.service/cpu.stat里面nr_throttled和throttled_usec如果明显变大说明节流机制在工作。没有这一步你永远不知道 CPUQuota 到底是被 systemd 吞了、还是根本没进内核。4.4 日志里哪些信息值得盯限制生效后agent 的死亡方式也会变化日志是判断问题的重要入口。journalctl -u collect-agent -e如果看到进程以 KILL 信号退出去查内核日志确认是不是 cgroup OOMjournalctl -k | grep -i out of memory这里有一个很容易误判的细节cgroup OOM 杀的不一定是主进程而是 cgroup 内内核 OOM score 最高的坏分子。如果 agent 是多进程结构某次 OOM 可能只杀掉了其中一个子进程主进程还活着unit 状态还是 active(running)但业务功能已经残了。这就是我在 unit 里写 OOMPolicystop 的原因——它让 systemd 在检测到 cgroup OOM 事件时直接把整个 unit 停掉配合 Restarton-failure 干净地重启而不是留着半死不活的主进程继续误导监控。5. 我踩过/见过的坑delegation、swap 和看起来生效5.1 控制器没被启用时限额会静默失效最常见的假生效场景配置写了 MemoryMaxsystemctl status 也显示 Memory 行但内存还是蹭蹭往上涨。先别怀疑内核去查 system.slice 的 subtree_controlcat /sys/fs/cgroup/system.slice/cgroup.subtree_control如果里面没有 memory 这个关键字说明 memory 控制器根本没在这个层级启用你写的 MemoryMax 不会被内核执行。根因一是 systemd 太老二是内核引导参数把控制器禁了三是某些虚拟机镜像本身没把控制器配全。现场临时救火可以手动写echo memory /sys/fs/cgroup/cgroup.subtree_control但重启后可能恢复原样正式修复要回到内核参数和 systemd 版本层面。我建议在装 agent 之前就把这一步纳入机器初始化检查脚本别等事故再发现。5.2 swap 不设防memory.max 就是半扇门cgroup v2 里 memory.max 管的是内存这一项swap 是单独记账的对应 memory.swap.max。主机开了 swap 的情况下进程在内存达到上限后可以先换页到 swap 里继续苟活代价是整台机器进入 swap 抖动业务进程全部跟着遭殃。所以 MemorySwapMax0 几乎是 agent 限制里的必选项。这把内存 swap的总量彻底关死内存到顶swap 也不让用内核只能回收或者 OOM。说白了对 agent 这种可以随时重启的进程宁可让它死得痛快也不能让它带着宿主机一起慢性失血。5.3 page cache 会把 memory.current 撑得虚高cgroup v2 的 memory.current 不是匿名内存里面包含 page cache。采集 agent 如果频繁读文件读进来的文件页会记到这个 cgroup 头上memory.current 可能虚高到接近 Max但实际程序 RSS 并不高一查 memory.statfile 部分占了大头。这个坑会造成两种误判一是你监控看到内存快爆了很紧张实际上这些 cache 是可以随时回收的二是如果 Max 设得太死agent 只是多读了几份大文件就可能被 OOM。对策是对读文件量大的 agentMemoryMax 要留出 cache 的余量并让 MemoryHigh 发挥作用——内核超了 high 会优先回收 cache而不是动匿名内存。这个机制其实是保护你的关键是要给它空间。5.4 OOMPolicy 和 TasksMax 的默认行为OOMPolicy 的默认值是 continue意思是 cgroup 内发生 OOM 时systemd 不做额外动作让内核杀完就完了。但这会导致前面说的主进程还活着unit 还在 running的情况。如果你希望 OOM 时整个服务干净重建明确写 OOMPolicystop 或 kill。stop 会正常停止整个 unitkill 会直接杀光 cgroup 内所有进程。agent 场景我推荐 stop。TasksMax 也有默认值的坑。你不写这个字段systemd 会套用一个全局默认值不同发行版不一样常见的是某个固定数值或按 pids 控制器上限的一定比例折算。如果你的 agent 是重线程池模型默认值可能过小莫名其妙的 fork 失败反过来也不要随手写 infinity——那等于把 pids 限制整个关掉就失去了防线程泄漏的意义。5.5 Delegateyes 不是越多越好如果 agent 自己需要管理嵌套 cgroup比如它内部有容器运行时、或者要实现类似 serverless 的进程隔离就必须在 unit 里写 Delegateyes。这个字段的意思是systemd 把这个 unit 的整棵子树控制权交出去包括 subtree_control 的控制器开关权限都归 agent 自己管。但别因为听起来很强大就随手开。Delegateyes 意味着系统服务管理器放弃了对这棵子树的资源控制器管理权配合 NoNewPrivileges 之类的安全加固时语义也会变得复杂。普通采集 agent 根本不需要管子 cgroup保持默认就好。这个选项只在agent 确实要创建自己的 cgroup 层级时才打开而且开了之后要重新审视整棵树的资源如何逐层分配。6. 不写 unit 也能限制systemd-run 与 slice 聚合的玩法6.1 临时进程快速限流systemd-run 一把梭有些 agent 不是 systemd 管理的可能是 crontab 调起的批处理任务也可能是某个老 supervisor 拉起的常驻进程。临时想给它加限制不用非得写 unit 文件systemd-run 一条命令就能包一层 scopesystemd-run --scope -p MemoryMax500M -p CPUQuota100% -- /opt/legacy-agent/bin/agent --foreground--scope 的意思是这个进程是外部启动的我用 scope 把它圈起来限制字段用 -p 传跟 unit 里完全同源。对于已经跑起来的进程也可以先起一个 scope 再把它手动挪进去systemd-run --scope --unitrescue-scope -p MemoryMax500M sleep 1000000 echo 12345 /sys/fs/cgroup/system.slice/rescue-scope.scope/cgroup.procs用cat /proc/12345/cgroup确认它确实落在了新的 scope 里。这是线下救火的土办法重启后会失效正式环境还是建议规规矩矩写 unit、纳管进配置仓库。6.2 用 slice 把多个 agent 关进同一个资源池机器上往往不止一个 agent采集、日志、备份、指标上报各有各的 unit。单独给每个都设上限可能出现A 闲着、B 把整机吃爆的局面更合理的是把它们放进同一个 slice共享一份资源预算。# /etc/systemd/system/agents.slice [Unit] DescriptionAgent Resource Pool [Slice] MemoryMax4G MemorySwapMax0 CPUQuota400% TasksMax2048 IOWeight20然后在每个 agent 的 unit 里加一行Sliceagents.slice这样四个 agent 共享 4GB 内存、4 个核的配额任何一个都不能独吞整份预算。slice 层的限制和 unit 自己的限制是叠加关系unit 里不设的就受 slice 约束unit 里设的更精细的则两者都生效。监控时直接看/sys/fs/cgroup/agents.slice/下的文件一组 agent 的总消耗一目了然。6.3 热调整set-property 和事后监控资源限制配好不是一劳永逸agent 业务模型变了、数据量涨了配额也得跟着动。systemd 支持热调整不用改文件、不用重启服务systemctl set-property collect-agent.service MemoryMax800M systemctl set-property --runtime collect-agent.service CPUQuota200%不带 --runtime 的调整会持久化到 drop-in 文件重启后依然生效带 --runtime 的只对当前启动生效。用systemctl show collect-agent.service -p MemoryMax -p CPUQuota -p TasksMax可以随时查看当前生效值。我自己的节奏是刚上线的 agent 先给 MemoryHigh 留出缓冲观察两周 memory.events 里的 high/max/oom 计数再决定要不要把 Max 收紧CPU 则优先用 Quota 硬隔离避免它在业务高峰期抢算力。agent 进程说白了是可丢弃的让它快速 OOM、自动重启比让它把宿主机拖垮再被大家一起 OOM 要划算得多。说句实在话资源限制这件事配置本身不难难的是验证和边界判断。我的经验是每次改完都要走一遍读 cgroup 文件 压力测试 看 events 计数这三步形成习惯。这套 systemd cgroups v2 的组合到目前为止是我见过对 agent 类进程最省心的约束方案没有之一。
