PHP-FPM 进程模型与 pm.max_children 计算与压测验证

目标：在生产中合理设置 `pm.max_children`，既不因内存溢出崩溃，也不造成过度竞争。本文提供测量与计算公式，并用压测验证。

## 模式与参数

• `pm = static|dynamic|ondemand`：建议高并发场景用 `dynamic` 或 `static`。
• 关键参数：`pm.max_children`、`pm.start_servers`、`pm.min_spare_servers`、`pm.max_spare_servers`、`pm.max_requests`。

## 测量单子进程占用（可复现）

1. 关闭非必要扩展，确认 Opcache 开启。

2. 压测期间观察 RSS：

ps -o pid,rss,comm -p $(pgrep -d',' php-fpm)

记录稳定阶段子进程的平均 RSS（如 80–120 MB/进程）。

## 计算公式（实用）

pm.max_children ≈ floor((可用内存 - 预留) / 单子进程RSS)

示例：可用 16 GiB，预留 2 GiB 给 Nginx/系统与缓存，单子进程 RSS ≈ 100 MB，则：

pm.max_children ≈ floor((14 GiB) / 100 MB) ≈ 143

## 压测验证（wrk）

wrk -t8 -c256 -d60s http://app.example.com/

观测：

• 吞吐（Requests/sec）、P95/P99 延迟。
• 系统层：`vmstat`/`pidstat`/`sar` 观察上下文切换与 CPU 利用率。

## 进一步优化

• 启用 Opcache，降低脚本编译开销：

opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=50000

• 合理 `pm.max_requests`（如 500–2000）避免长期内存碎片。
• 结合 `slowlog` 抓取慢脚本定位热点。

## 注意事项

• RSS 会随业务与扩展变化，需在真实流量或相似压测下测量。
• `static` 模式易获得稳定延迟，但内存峰值高；`ondemand` 适合低负载但冷启动延迟大。
• 保留足够内存给数据库客户端、缓存与系统页缓存，避免 OOM。

## 结语

以测量为基准计算 `pm.max_children`，再通过压测与系统观测验证，是将 PHP-FPM 配置落入“可复现与可维护”范畴的关键实践。