systemd可通过修改Nginx service单元文件直接限制其内存（MemoryMax=512M）、内存回收阈值（MemoryHigh=400M）、禁用swap（MemorySwapMax=0）、CPU配额（CPUQuota=50%）和进程数（TasksMax=256），并需配合Nginx自身配置（如固定worker_processes）以确保生效。
systemd 可以对 Nginx 服务进行精细的内存与资源限制，无需依赖外部工具（如 cgroups v1 手动配置），只需修改其 service 单元文件即可生效。关键在于正确使用 systemd 的资源控制指令，并注意 Nginx 自身多进程模型的影响。
设置内存上限（MemoryMax）
通过 MemoryMax 限制 Nginx 主进程及其所有子进程（worker 进程、cache manager 等）使用的总物理内存。超出时 systemd 会触发 OOM killer 终止该服务。
- 编辑 Nginx service 文件：
sudo systemctl edit nginx（推荐方式，避免覆盖包管理器更新） - 添加如下内容：
[Service] MemoryMax=512M
- 保存后重载配置：
sudo systemctl daemon-reload，再重启服务：sudo systemctl restart nginx - 验证是否生效：
systemctl show nginx --property=MemoryMax或查看 cgroup 路径：cat /sys/fs/cgroup/system.slice/nginx.service/memory.max
限制内存+swap 使用（MemoryHigh 与 MemorySwapMax）
MemoryHigh 是更温和的限值：达到后内核会主动回收该服务的内存页（如 page cache、匿名页），但不会立即 kill；MemorySwapMax 控制可使用的 swap 总量（设为 0 可禁用 swap）。
- 示例配置（平衡响应性与稳定性）：
[Service] MemoryHigh=400M MemoryMax=512M MemorySwapMax=0
- 适合生产环境：MemoryHigh 触发压力回收，MemoryMax 作为硬性兜底
- 注意：启用 swap 会削弱 MemoryMax 的保护效果，建议关闭（尤其 SSD 服务器）
约束 CPU 与进程数（CPUQuota 和 TasksMax）
Nginx 在高并发下可能创建大量临时进程（如 CGI、proxy_pass 子请求）或因配置不当 fork 过多 worker。配合内存限制，需同步控制 CPU 时间和并发任务数。
- CPUQuota=50%：限制 Nginx 最多使用单个 CPU 核心的 50%（即 0.5 核），防止抢占系统其他服务
- TasksMax=256：限制该服务能创建的总线程/进程数（包括主线程、worker 进程、timer、cache loader 等），避免 fork bomb 类风险
- 若使用
worker_processes auto，建议显式设为固定值（如worker_processes 4），避免 TasksMax 被动态 worker 数意外触达
验证与调试技巧
配置生效后，需确认实际行为符合预期，而非仅看参数是否写入。
- 实时监控内存使用：
systemctl status nginx（含 MemoryCurrent）、或systemd-cgtop - 检查 OOM 事件：
journalctl -u nginx -g "Out of memory"或dmesg -T | grep -i "killed process" - 观察 worker 行为：
ps -o pid,ppid,rss,comm -C nginx查看各进程内存占用，确认未突破 MemoryMax 总和 - 若发现频繁被 kill 但 RSS 显示不高，可能是 Nginx 开启了
ssl_buffer_size或大 body 缓存导致内核页分配激增，需调低client_max_body_size或优化 SSL 设置
不复杂但容易忽略：Nginx 的 master 进程本身内存开销小，真正吃内存的是 worker 进程 —— 所有资源限制都作用于整个 cgroup，包含所有子进程。合理设置 worker_connections 和 worker_rlimit_nofile（在 nginx.conf 中），才能让 systemd 的内存策略真正落地。
