Linux cgroup v2 pids.max 到底限制了谁：pids.current、pids.events 与 TasksMax 联动排查

线上服务还能正常读写磁盘，内存和 CPU 也没跑满，却突然报“无法创建新线程”。这类故障很容易被误判成应用线程池问题；如果进程所在的 cgroup 触到了任务数上限，新的线程或子进程同样会被内核直接拒绝。先看 pids.current、pids.max 和 pids.events，再确认服务管理器的 TasksMax=，通常几分钟就能判断限制来自哪一层。

pids.current 接近或超过 pids.max，同时 pids.events 的 max 增长，才说明 cgroup PID 限制真正参与了故障；只查到线程池配置异常，并不能证明它就是根因。

先把“线程创建失败”与 PID 上限对上

Linux cgroup v2 的 PID controller 管的是内核任务总数，线程也被算在统计范围内。应用日志里常见的现象是线程创建返回失败、短时间重试后服务降级，或者独立的 worker 进程无法正常拉起。此时不要上来就把 ulimit -u 调大：那是用户级限制，和 cgroup 的 pids.max 是两条完全独立的校验链路。

先找到服务对应的 cgroup 路径：

unitctl show order-worker.service -p ControlGroup -p TasksMax
unitctl status order-worker.service --no-pager

假设返回路径是 /service.slice/order-worker.service，再读取对应文件夹下的文件：

CG=/sys/fs/cgroup/service.slice/order-worker.service
cat "$CG/pids.current" "$CG/pids.max" "$CG/pids.peak"
cat "$CG/pids.events" "$CG/pids.events.local"

四个关联文件要一起看，避免误判

pids.max：硬上限，不是参考建议值

非根 cgroup 才有可写的 pids.max，默认值通常是 max。它限制的是该层级能容纳的任务总数；父级如果设置了更小的值，子级写得再大也绕不过父级的更严格限制。临时把值改得比当前任务数更小，还可能出现 pids.current > pids.max 的现象，因为整理进程或迁移进程不会被这个策略拦截，真正被拒绝的只有后续新创建的任务。

pids.current：包含后代任务，别只数主进程

一个主 worker 自己只有几十个进程，不代表整个服务只占用了几十个任务额度。它启动的子 worker、脚本进程以及内部所有线程都会落在这个统计范围内。发现数值异常时，顺手看一眼直属成员和下属子 cgroup：

cat "$CG/cgroup.procs" | wc -l
find "$CG" -mindepth 1 -maxdepth 1 -type d -print

前一条命令只是直属进程的粗略数量，不能替代 pids.current 的统计结果；两者差距很大时，通常说明大量线程或者后代 cgroup 正在消耗额度。

pids.peak：故障已经过去，也能留下有效线索

如果告警到达时服务已经自动回收了多余 worker，pids.current 可能已经恢复到正常水平。这时 pids.peak 可以证明它曾经冲到过更高的水位。把它和应用日志的时间、worker 数量变化放在一起对照，比单看当前值可靠得多。

pids.events 与 pids.events.local：统计层级口径不同

pids.events 的 max 记录触及上限的总次数；在默认语义下，父 cgroup 的统计可能包含子树所有节点发生的限制事件。需要确认“到底是哪一级自己撞的上限”时，再读取 pids.events.local 的内容。如果 max 一直是 0，就不要仅凭“线程创建失败”四个字把问题归给 cgroup。

服务管理器的 TasksMax=是最常见的配置入口

由服务管理器托管的服务，不建议直接修改运行中的 cgroup 文件作为长期修复方案。先查看 unit 的实际生效属性：

unitctl show order-worker.service -p TasksMax -p ControlGroup
unitctl cat order-worker.service

如果 unit 文件或者 drop-in 配置中存在 TasksMax=128，而服务的线程池、子进程数量已经接近这个值，优先在 drop-in 配置中调整数值，同时保留旧的配置记录：

sudo unitctl edit order-worker.service

[Service]
TasksMax=512

保存后重载配置并重启服务，再检查实际生效值和事件计数：

sudo unitctl daemon-reload
sudo unitctl restart order-worker.service
unitctl show order-worker.service -p TasksMax -p ControlGroup
CG=/sys/fs/cgroup/service.slice/order-worker.service
cat "$CG/pids.current" "$CG/pids.max" "$CG/pids.peak" "$CG/pids.events"

修复后怎么判断是真的恢复正常

不要只看服务状态变成 active (running) 就认为问题搞定了。至少留四组校验证据：

• 配置：unitctl show 返回的 TasksMax 和预期配置一致。
• 路径：ControlGroup 指向正在运行的 unit，而不是旧版本残留或者临时 scope。
• 容量：pids.current 明显低于 pids.max，新的 worker 能正常创建出来。
• 事件：观察窗口内 pids.events 的 max 不再增长，业务日志里的线程创建失败也完全停止。

如果只改了 unit 配置，却发现 cgroup 的 pids.max 仍然没有变化，先确认服务管理器是否重新创建了服务对应的 cgroup，以及上级 slice 是否还有更小的 TasksMax=。PID 限制是层级生效的，子级放宽不能覆盖祖先节点更严格的限制。

常见误区和回滚边界

第一，别把 pids.max 当成“进程数报警阈值”。它是硬限制，设置得太贴近日常峰值会把一次正常发布或者流量突增变成线程创建失败。第二，别只看 pids.current 的瞬时值；如果峰值已经回落，pids.peak 和事件计数才是定位根因的关键。第三，别只在 unit 文件里搜配置，drop-in、slice 和模板服务都可能改变最终生效值。

回滚时恢复原来的 TasksMax，再次执行 daemon-reload 和服务重启，然后保留一段观察窗口。如果服务后续仍需更多任务额度，应该先拆分 worker、限制子进程增长或者调整发布并发，再决定是否提高硬上限，而不是无限制地写成 infinity 或者依赖重启临时缓解问题。

相关问题

pids.max 和 ulimit -u 有什么区别？

pids.max 按 cgroup 层级限制任务数，ulimit -u 按用户身份限制可创建的进程/线程数；其中一个放宽后，另一个仍可能拒绝新任务的创建请求。

pids.current 超过 pids.max 一定是配置失效吗？

不一定。手动降低上限或者迁移现有进程可能让当前值暂时超过上限；这个策略主要是阻止后续的新任务创建调用，不会主动清理已经存在的任务。

为什么 pids.events 有 max 计数，但本服务没有撞限制？

父 cgroup 的事件统计可能包含子树节点触发的记录。需要定位本组触发情况时同时读取 pids.events.local，并确认读取的是当前 unit 的实际 cgroup 存储路径。

只重启服务能解决问题吗？

重启会清掉旧任务，可能让 pids.current 暂时下降，但不会改变 TasksMax 或者祖先 cgroup 的硬限制；它只能作为临时恢复动作，不能替代配置调整和容量分析。

遇到“资源看着都够用，却不能创建新任务”时，按 ControlGroup → pids.max → pids.current/pids.peak → pids.events.local → TasksMax 的顺序检查，拿到的证据会比盲目调大线程池更快完成故障闭环。