Nginx多进程模型不支持单个worker进程级资源配额，必须通过systemd对整个服务进程树（master+workers）统一限制；需配置MemoryMax、CPUQuota等参数并启用cgroup v2（Delegate=yes、MemoryAccounting=yes），配合LimitNOFILE和TasksMax实现整体资源管控与隔离。
Nginx 多进程模型本身不提供进程级资源配额（如每个 worker 单独限 CPU 或内存），它依赖外部运行环境统一管控整个服务进程树（master + all workers）。真正有效的资源限制必须作用于进程组层面，而非单个 worker 进程。
Nginx 自身配置只能约束并发行为，不能限制资源用量
worker_processes 和 worker_connections 属于调度与连接数控制，不是资源配额：
-
worker_processes auto或设为具体数值，仅决定启动几个独立 worker 进程 -
worker_connections 1024表示每个 worker 最多处理 1024 个并发连接，影响 socket 数量，但不阻止该进程吃满内存或 CPU - 这些参数不触发 cgroup、不设内存上限、不分配 CPU 时间片
systemd 是主流且推荐的进程级资源管控方式
Nginx 作为 systemd 服务运行时，可通过 override 配置对整个服务单元施加硬性限制：
-
MemoryMax=512M：整个 Nginx（master + 所有 workers）内存使用不可超此值，超限时内核 OOM killer 可能终止进程 -
CPUQuota=30%：在所有 CPU 核心上总计最多占用 30% 的时间（例如 4 核机器 ≈ 相当于 1.2 核持续满载） -
TasksMax=64：限制该服务下总进程/线程数（含 master、workers、临时子进程），防 fork 爆炸 -
LimitNOFILE=65536：设置 open files 上限，直接影响最大并发连接能力
需配合 cgroup v2 启用才能生效
现代 Linux（内核 ≥ 4.15，systemd ≥ 230）默认启用 cgroup v2，但需确认：
-
systemctl show nginx --property=Delegate应返回Delegate=yes（允许子 cgroup 创建） -
systemctl show nginx --property=MemoryAccounting应为true（开启内存统计） - 若未启用，
MemoryMax等参数将被忽略
验证是否生效的三个关键检查点
- 查看当前内存使用：
cat /sys/fs/cgroup/system.slice/nginx.service/memory.current - 查看内存上限：
cat /sys/fs/cgroup/system.slice/nginx.service/memory.max - 检查主进程资源限制：
cat /proc/$(pgrep nginx | head -n1)/limits | grep "Max open files"
不要尝试给单个 worker 进程单独设限
Nginx worker 是由 master fork 出的同用户、同命名空间下的普通进程，无法也不应被单独分配不同配额。强行隔离（如用 pid cgroup 手动划分）会破坏共享内存通信机制，导致 limit_req_zone、SSL 缓存等跨进程功能失效。
资源配额必须面向服务整体设计，而不是拆解到每个 worker。
