pm.max_children需按可用内存÷单进程RSS向下取整计算，禁用CPU核数硬套；dynamic模式下按start_servers=核数×2、min_spare=0.5×start、max_spare=2×start梯度配置；同步启用OPcache、Unix Socket及慢日志定位瓶颈。
PHP 8.0 下优化 PHP-FPM 池参数，核心不是堆进程数，而是让每个进程“用得稳、退得巧、等得短”。重点围绕内存可用量、单进程真实 RSS、请求波动特征来设值，避免 OOM 或排队堆积。
算准 pm.max_children：按内存，不按 CPU 核数
这是最关键的一步。服务器总内存减去系统和其他服务（Nginx、MySQL、Redis 等）占用后，才是 PHP-FPM 可用内存。再除以单个 PHP 进程的真实内存占用（RSS），结果向下取整即为安全上限。
- 查真实 RSS：运行 ps --no-headers -o rss -C php-fpm | awk '{sum+=$1} END {print int(sum/NR/1024)" MB"}'，典型 Laravel/Symfony 项目常达 80–120MB；轻量脚本可能仅 20–40MB
- 举例：16GB 服务器，留 4GB 给系统和数据库 → 可用 12GB；若单进程占 100MB，则 pm.max_children ≤ 120（12288 ÷ 100 ≈ 122，向下取整为 120）
- 宝塔默认 50 是小站友好值，高并发场景下往往严重偏低，但盲目拉到 200 就极易触发 OOM Killer
选对 pm 模式并设好动态伸缩边界
PHP 8.0 推荐使用 pm = dynamic，它比 static 更适应流量峰谷，也比 ondemand 更快响应突发请求。
- pm.start_servers：设为 CPU 核数 × 2（如 4 核 → 8）。太低会卡在 fork 新进程上；太高冷启动就吃光空闲内存
- pm.min_spare_servers：设为 start_servers 的 0.5 倍（如 8 → 4），保证总有空闲进程接新请求
- pm.max_spare_servers：设为 start_servers 的 2 倍（如 8 → 16），防止空闲进程过多浪费资源
- 确保 min_spare ≤ start_servers ≤ max_spare ≤ max_children，否则配置不生效
设好 pm.max_requests 防止内存缓慢泄漏
PHP 8.0 虽改善了内存管理，但复杂框架或扩展（如 Xdebug、某些 PDO 驱动）仍可能随请求累积微量泄漏。定期重启 Worker 是性价比最高的兜底手段。
立即学习“PHP免费学习笔记（深入）”；
- 设为 1000–3000 较稳妥：太小（如 500）导致频繁 fork，CPU 负载升高；太大（如 0 或 10000）可能让泄漏积累到影响稳定性
- 观察 php-fpm status page 中的 max active processes 和 slow requests，若活跃进程长期接近 max_children 且 slowlog 频发，说明不只是参数问题，需查脚本
配套必须做的三件事
光调池参数不够，以下三项不落实，再优的配置也白搭：
- 启用 OPcache：PHP 8.0 默认开启，但需确认 opcache.enable=1 且 opcache.memory_consumption≥128；关闭 opcache.validate_timestamps（开发环境除外）可进一步提速
- 改用 Unix Socket 通信：Nginx 的 fastcgi_pass 指向 unix:/run/php/php8.0-fpm.sock，比 TCP localhost:9000 减少网络栈开销，尤其在高并发时更明显
- 开慢日志定位真瓶颈：在 pool 配置中加 slowlog = /www/wwwlogs/php_slow_80.log 和 request_slowlog_timeout = 2s，再配合宝塔或命令行查日志，找到拖慢整个池子的接口或 SQL
