Nginx Master Process不执行资源限制，仅协调worker进程；资源约束须由systemd统一管控整个nginx.service单元，并配合worker_processes固定、worker_rlimit_nofile调优等Nginx自身配置协同生效。
Nginx 的 Master Process 本身不直接施加或执行资源限制（如内存、CPU、文件句柄数），它只负责协调、派生和监管 Worker 进程，真正的资源约束需由操作系统层（systemd/cgroups）或内核参数配合 Nginx 自身配置共同实现。
Master Process 的角色定位决定它不管理资源配额
Master 进程以 root 权限启动，仅做以下几件事：解析配置、预分配监听套接字、fork 出 Worker 进程、响应信号（如 reload/stop）、监控 Worker 状态并异常重启。它不处理请求、不分配内存页、不调度 CPU 时间片，因此不会读取或应用 memory.max、CPUQuota 等资源策略——这些是 systemd 或 cgroup v2 对整个服务（包括 master 及其所有子进程）统一施加的控制。
资源限制必须作用于整个 nginx.service 单元
要限制 Nginx 整体资源，需修改其 systemd service 文件，例如：
[Service] MemoryMax=512M MemoryHigh=400M MemorySwapMax=0 CPUQuota=50% TasksMax=256
该配置生效后，systemd 会将 master 进程及其所有子进程（worker、cache manager、cache loader）纳入同一 cgroup，统一受控。Master 进程只是这个 cgroup 中的第一个进程，不是控制器。
Nginx 自身配置需与系统限制协同
仅靠 systemd 限制不够，还需适配 Nginx 内部行为，避免因配置不当绕过或触发边界问题：
-
worker_processes auto应改为固定值（如worker_processes 4），否则在多核机器上可能意外拉高TasksMax触发限制 -
worker_rlimit_nofile必须设为足够大（如65536），且要高于 ulimit -n 设置，否则即使 systemd 没限文件数，Nginx 也会报 “Too many open files” -
worker_connections需结合worker_rlimit_nofile和预期并发量设置，防止连接耗尽导致 accept 失败
验证是否真正受限
不能只看配置是否写入，要检查实际 cgroup 状态：
# 查看内存上限是否生效 cat /sys/fs/cgroup/system.slice/nginx.service/memory.max # 查看当前内存使用 cat /sys/fs/cgroup/system.slice/nginx.service/memory.current # 检查 TasksMax 是否被触发（查看拒绝日志） journalctl -u nginx | grep "tasks\|cgroup"
Master Process 不参与这些数值的计算或决策，但它会因子进程被 cgroup OOM killer 终止而收到 SIGCHLD，并按需拉起新 Worker —— 这是它唯一“响应”资源限制的方式。
