PHP-FPM 的 process manager 模式仅有 static、dynamic、ondemand 三种，均基于 prefork 模型，不支持 event 或 threaded 模式；修改需编辑 pool 配置文件中 pm 相关参数，并执行 systemctl reload php{version}-fpm 生效。
PHP-FPM 的 process manager 模式有哪些
PHP-FPM 只有三种 pm（process manager）模式：static、dynamic、ondemand。没有 “event” 或 “threaded” 这类模式——PHP 不支持多线程 FPM，所有模式都基于 prefork（预派生）模型，只是子进程生命周期和数量策略不同。
如何修改 pm 模式并生效
修改位于 /etc/php/{version}/fpm/pool.d/www.conf（或对应 pool 配置文件）中的以下几行：
pm = dynamic pm.max_children = 50 pm.start_servers = 5 pm.min_spare_servers = 5 pm.max_spare_servers = 35
注意：pm = ondemand 时，pm.start_servers 无效，且必须显式设置 pm.max_children 和 pm.process_idle_timeout（如 pm.process_idle_timeout = 10s）；
pm = static 时，只认 pm.max_children，其余 pm.*_servers 参数会被忽略。
改完后必须执行：
sudo systemctl reload php{version}-fpm（不是 restart，reload 才能热切换 worker 进程池策略）。
不同 pm 模式对内存和并发的实际影响
static：固定常驻 pm.max_children 个子进程，启动即分配全部内存，适合稳定高并发、内存充足场景；但突发流量低谷时无法释放空闲进程，浪费内存。
dynamic：最常用，默认配置较保守；min_spare_servers 和 max_spare_servers 控制空闲进程上下限，start_servers 是启动时生成数；扩容缩容有延迟（依赖 pm.max_requests 和心跳检查），不适合秒级突增流量。
ondemand：启动时 0 个子进程，请求来时才 fork，空闲超时即销毁；单次请求延迟略高（fork 开销），但内存占用最低；适用于低频、间歇*务（如后台 API、定时任务触发接口），**不适用于 Nginx + fastcgi_cache 场景**——因为 cache miss 后首次请求 fork 延迟明显，会破坏缓存命中体验。
切模式前必须检查的三个配置项
很多切换失败或效果异常，其实是因为忽略了关联参数：
-
pm.max_requests：无论哪种模式，该值过小（如设为 10）会导致子进程频繁重启，表现为日志里大量WARNING: [pool www] child 123 exited on signal 15 (SIGTERM) after X seconds from start -
rlimit_files：尤其在static模式下，每个子进程都持有一批文件描述符（socket、log、opcache 等），若系统级限制太低（ulimit -nfailed to open stream: Too many open files -
catch_workers_output = yes：切换过程中若子进程崩溃，不开启此选项将看不到 stderr 输出，难以定位是 opcache 配置冲突还是扩展初始化失败
