批量并发脚本一开跑就成片报 fork: retry: Resource temporarily unavailable，机器内存还剩一半 CPU 也不忙，把并发数降下来就能缓过来，很难判断卡在哪一层。乍看像缓存或者权限的锅，追下去往往不是。
cat /sys/fs/cgroup/pids.max /sys/fs/cgroup/pids.current ulimit -u; sysctl kernel.pid_max kernel.threads-max ps -eLf | wc -l sudo sysctl -w kernel.pid_max=4194304
追下去是这么回事：系统 pids cgroup 或 kernel.pid_max 已经到顶，也可能是用户级 nproc 限制，进程数上限和内存余量没有关系，三个口子要分别确认，方向错了会白折腾很久，先分清再动手。
「pids cgroup 上限」这类改动最怕改一半，回滚脚本先准备好，再动生产。测试环境和线上的差别，往往就在版本号和那几行被忽略的配置上。
线上出问题先对时间点，跟发布、备份、任务执行的时刻排一排，能省掉一半功夫。
具体做法是，先读 pids.current 与 pids.max 判断是否真的贴近上限 确认系统层面的进程数水位；再对照 ulimit -u 和 limits.conf 里的 nproc 设置找差额 两处限制取的是更小的那个；把并发 worker 数降下来 或者调大 pids.max 之后重新压测 观察报错是否消失。
验收就看一点，压测期间 pids.current 稳定在 pids.max 的七成以下 并且 fork 报错完全消失 连续跑十分钟。