Linux 上提升 PHP-FPM 处理速度的系统化做法
一 核心原则与快速判断
- 优先减少阻塞与等待：启用并正确配置 OPcache，对静态资源交由 Nginx/Apache 直接处理，避免把图片、CSS、JS 打到 PHP-FPM。
- 降低通信开销：使用 Unix Socket 替代 127.0.0.1:9000，减少网络栈与端口开销。
- 匹配并发与资源：按内存与 CPU 规划进程数量，避免 pm.max_children 过大导致换页/内存耗尽，或过小导致排队。
- 发现瓶颈再优化：打开 慢日志 定位耗时脚本，配合 状态页 与系统监控观察排队、进程利用率与错误。
二 PHP-FPM 进程与连接优化
- 进程管理模式选择
- dynamic：按负载增减，适合大多数场景；需合理设置起停与空闲进程带，减少频繁创建销毁。
- ondemand：按需拉起，适合低并发/突发流量，注意冷启动延迟与 pm.process_idle_timeout 配置。
- static：进程数固定，适合稳定高并发且资源充足的环境。
- 关键参数建议（示例为 dynamic，需按机器内存与实测调整）
- 计算可用内存：可用内存 ≈ 总内存 − 系统/数据库/缓存占用。每进程内存 ≈ 应用常驻内存 + 安全余量（建议预留 20%–30%）。
- 估算上限：pm.max_children ≤ 可用内存 / 每进程内存。例如：可用 4GB、每进程 80MB，则上限约 50；再结合压测微调。
- 常用组合示例（仅示例，务必压测后定稿）：
- pm = dynamic
- pm.max_children = 50
- pm.start_servers = 5
- pm.min_spare_servers = 5
- pm.max_spare_servers = 35
- 稳定性与可观测性
- request_terminate_timeout：请求最大执行时间，建议业务允许范围内设置，如 30s；设为 0 表示不主动终止（需配合慢日志与熔断策略）。
- request_slowlog_timeout：慢请求阈值，如 10s，并配置 slowlog 定位问题脚本。
- 监听方式：优先使用 listen = /run/php/php{version}-fpm.sock，性能通常优于 TCP 回环。
- 文件描述符：提升 ulimit -n，避免 “Too many open files” 限制并发与文件 I/O。
三 PHP 运行时与代码层优化
- 启用并优化 OPcache（php.ini）
- opcache.enable=1
- opcache.memory_consumption=128（MB）
- opcache.interned_strings_buffer=8
- opcache.max_accelerated_files=4000–10000（按代码规模）
- opcache.revalidate_freq=60（秒，开发环境可设更小）
- 生产建议关闭 display_errors，开启 log_errors，避免额外输出开销与信息泄露。
- 请求与资源限制（php.ini）
- memory_limit：按应用需求设置，如 128M–256M；避免过大导致 OOM 或过小频繁失败。
- max_execution_time：与业务 SLA 对齐，如 30–300s；配合慢日志与超时策略治理长请求。
- 数据层与缓存
- 引入 Redis/Memcached 做页面/数据缓存，减少数据库压力与慢查询。
- 优化 SQL：索引、批量操作、合理分页、连接复用/连接池（由应用或中间件实现）。
- 静态资源与网关职责划分
- 由 Nginx/Apache 直接服务静态文件（expires、gzip、cache-control），PHP-FPM 仅处理动态请求。
四 监控 日志与压测闭环
- 开启并定期查看
- 慢日志：slowlog 与 request_slowlog_timeout，定位最耗时调用链与 SQL。
- 错误日志：error.log 与 catch_workers_output，及时捕获启动/运行期异常。
- 访问日志：access.log 结合响应时间与状态码，发现异常流量与错误激增。
- 状态页与系统监控
- 启用 pm.status_path = /status，配合 Nginx 访问控制，观察 active processes、idle processes、requests、slow requests 等关键指标。
- 系统层面使用 top/htop、strace 等工具排查阻塞与系统调用瓶颈；必要时引入 Prometheus + Grafana 做长期可视化监控与告警。
五 安全可回滚的调优步骤
- 基线采集：记录当前 pm 参数、QPS、P95/P99、错误率、CPU/内存/负载与慢日志数量，作为回滚与对比基线。
- 只改一处：一次只调整一个关键参数（如 pm.max_children 或 opcache.revalidate_freq），观察至少 15–30 分钟 业务高峰。
- 压测验证：使用 ab/wrk/siege 或真实流量回放，逐步提升并发，观察队列、失败率与延迟拐点。
- 逐步放大：在稳定窗口内逐步放大并发与进程数，避免一次性跨越系统瓶颈。
- 固化与复盘：将有效配置写入版本管理，记录变更原因与效果；保留回滚方案，出现异常可快速恢复。