pm.max_children限制PHP-FPM同时处理请求的子进程数量。排队不一定靠调大解决：还需检查单请求耗时、实际进程内存、数据库及整机余量，否则更多进程可能引发内存压力和更严重的延迟。
先证明请求在等待PHP处理
同时记录流量时段、上游等待、FPM日志或状态、CPU、内存及数据库负载。静态资源慢、网络慢与PHP队列增长需要不同处理。状态页和慢日志可能包含敏感路径，不应直接开放给互联网作日常监控。
留出整台主机的共享资源
WordPress不是服务器上唯一的进程。操作系统、数据库、缓存、安全软件和其他站点都需要内存。估算单进程占用应使用代表性请求的实际观察，并考虑共享内存导致的统计差异，不能简单把PHP memory_limit当作固定进程大小。
结合进程模式小步调整
static、dynamic和ondemand的进程管理方式不同，但都需要正确理解并发上限。调整前保存池配置，并使用当前安装提供的配置检查。一次改变多个参数，会让后续难以判断改善来自并发变化还是其他条件。
以排队和业务表现共同判断
在受控负载或正常业务时段观察队列、响应、错误率与资源余量；需要时回退。数据库查询或外部接口耗时过长，应单独优化。不能承诺某个通用并发数适合所有WordPress，也不能把更多进程当作无限吞吐。
关键区别
并发上限：同时处理请求数；不是CPU核心数。
进程内存：按实际负载观察；不等于memory_limit。
整机余量：包括数据库等服务；避免把内存用尽。
怎样确认处理到位
代表性负载下队列、响应及错误率改善，CPU和内存仍有余量，其他站点与服务没有受损。
容易误判的边界
本篇给出容量判断方法，不提供无需测量即可照抄的参数。生产配置调整需要可回退窗口。
