cgroup限制PHP-FPM内存总量是最可靠手段——不依赖PHP配置，可硬隔离内存超限；推荐cgroup v2方式，通过memory.max设上限、memory.low启压力检测，并绑定systemd服务实现重启持久化。
直接用 cgroup 限制 PHP-FPM 进程的内存总量，是最可靠、最底层的防护手段——它不依赖 PHP 自身配置，也不受 memory_limit 或 pm.max_children 的干扰，能真正阻止单个 worker 或整组进程吃光服务器内存。
cgroup v2 方式（推荐，Ubuntu 20.04+ 默认启用）
现代 Ubuntu（22.04/24.04）默认使用 cgroup v2，操作更简洁、语义更清晰：
- 创建内存控制组：
sudo mkdir -p /sys/fs/cgroup/php-fpm - 设置内存上限（例如限制总内存为 2GB）：
echo 2G | sudo tee /sys/fs/cgroup/php-fpm/memory.max - 启用内存压力检测（可选但建议）：
echo 1 | sudo tee /sys/fs/cgroup/php-fpm/memory.low
（当内存紧张时，内核会优先回收该组内缓存） - 将当前所有 php-fpm worker 进程加入该组：
sudo pgrep -u www-data php-fpm | xargs -I {} sudo echo {} > /sys/fs/cgroup/php-fpm/cgroup.procs - 让后续新启动的进程也自动归属（需设 controller）：
echo "+memory" | sudo tee /sys/fs/cgroup/cgroup.subtree_control
再把 php-fpm 主进程（master）移到该组：echo $(pgrep -f "php-fpm: master") | sudo tee /sys/fs/cgroup/php-fpm/cgroup.procs
绑定到 systemd 服务（长期稳定方案）
比手动管理更稳妥，重启后自动生效。编辑 PHP-FPM 的 systemd 单元文件：
- 执行：
sudo systemctl edit php8.1-fpm（把8.1换成你实际版本） - 填入以下内容：
[Service]<br>MemoryMax=2G<br>MemoryLow=1G<br>MemorySwapMax=0
- 保存后重载并重启：
sudo systemctl daemon-reload && sudo systemctl restart php8.1-fpm
这样所有由该服务派生的进程（包括 master 和全部 worker）都会被统一约束在 2GB 内存上限下，超限时内核 OOM Killer 会精准杀掉该组内最“吃内存”的 worker，不影响其他服务。
立即学习“PHP免费学习笔记（深入）”；
为什么不能只靠 pm.max_children + memory_limit？
这两个参数组合存在明显盲区：
-
memory_limit=256M是每个脚本的软限制，但一个 worker 进程本身（含 Zend 引擎、OPcache、扩展内存等）常驻开销就可能达 30–50MB；若并发高、代码有泄漏或大对象未释放，单进程 RSS 可轻松突破 500MB -
pm.max_children=20看似总内存可控，但若每个 worker 实际占 600MB，20 个就是 12GB——远超 8GB 物理内存，触发系统级 OOM，可能误杀 MySQL 或 nginx - cgroup 是内核级硬隔离，只要设了
memory.max，超出即触发 OOM Killer 仅针对该组，不会波及其他进程
验证是否生效
运行以下命令确认限制已加载且进程归属正确：
- 查限制值：
cat /sys/fs/cgroup/php-fpm/memory.max - 查当前内存使用：
cat /sys/fs/cgroup/php-fpm/memory.current - 查哪些进程在组里：
cat /sys/fs/cgroup/php-fpm/cgroup.procs - 实时观察内存走势（每秒刷新）：
watch -n1 'cat /sys/fs/cgroup/php-fpm/memory.current'
看到数值稳定在设定上限附近、且不再飙升导致系统卡顿，说明防护已起效。
