Linux中PHP-FPM如何处理高并发请求

PHP-FPM 通过 多进程 + 队列 模型处理高并发请求。其核心流程如下：

1. 请求接入：Nginx 接收请求，若需 PHP 处理，则通过 FastCGI 协议转发给 PHP-FPM。
2. 进程分配：PHP-FPM 主进程（Master）根据配置策略，从进程池中分配一个空闲的 子进程（Worker） 来处理请求。
3. 脚本执行：子进程执行 PHP 脚本，期间可能访问数据库、缓存或外部 API。
4. 结果返回：脚本执行完毕后，子进程将结果返回给 Nginx，然后该子进程变为空闲状态，等待处理下一个请求。

当并发请求数超过 pm.max_children 时，新请求会在 FPM 内部队列中等待，若队列也满了，Nginx 便会返回 502/504 错误。因此，优化高并发的关键在于 合理设置进程模型与数量、减少单请求耗时、并协同 Nginx 与 Linux 系统。

⚙️ 核心优化策略

1. 进程管理模式 (pm)

在 www.conf 中配置，决定了子进程的创建和管理方式。

建议：优先使用 dynamic 模式，待流量稳定且资源充足时，可尝试 static 模式以追求更高性能。

2. 进程数量与资源配置

合理配置进程数是避免资源浪费或请求排队的关键。

• pm.max_children (最大子进程数)

  • 估算公式：可用内存 ÷ 单进程峰值内存
  • 示例：服务器可用内存 4GB，单进程峰值内存 80MB，则 max_children 理论上限约为 50 (4000MB / 80MB)。务必为系统和其他服务预留 20-30% 的内存。

• pm.start_servers (初始进程数)

  • 建议值：约等于常态下的并发请求数，或 CPU核心数 × 2～4。

• pm.min_spare_servers / pm.max_spare_servers (空闲进程数)

  • 建议值：min_spare_servers 可设为 CPU核心数 × 2，max_spare_servers 可设为 CPU核心数 × 4。这能让 FPM 平滑应对流量突增。

• pm.max_requests (进程重启周期)

  • 建议值：500～1000。用于周期性重启子进程，以缓解潜在的内存泄漏和内存碎片问题。

3. 请求生命周期与超时控制

防止个别慢请求耗尽所有进程资源。

• request_terminate_timeout：脚本最大执行时间。API 接口建议 15～30s，后台任务可酌情延长。设为 0 表示不主动终止，需配合慢日志和熔断策略。
• request_slowlog_timeout & slowlog：记录执行时间超过阈值的“慢请求”及其调用栈，是定位性能瓶颈（如慢 SQL、复杂逻辑）的利器。
• Nginx 超时：需与 FPM 配置协同，避免 Nginx 超时断开而 FPM 仍在执行。
  • fastcgi_read_timeout
  • fastcgi_send_timeout

4. 通信方式与系统限制

减少通信开销，并解除系统层面的资源瓶颈。

• 监听方式 (listen)
  • Unix Socket (推荐)：listen = /run/php/php-fpm.sock。本地通信，性能优于 TCP，开销更小。
  • TCP Socket：listen = 127.0.0.1:9000。适用于容器或跨主机通信。
• 文件描述符 (ulimit)
  • 提高系统及 PHP-FPM 进程的文件描述符限制，防止出现 “Too many open files” 错误。
• 内核参数
  • 可适当调大 net.core.somaxconn (监听队列长度) 和 net.ipv4.tcp_max_syn_backlog (SYN 队列长度)，以应对瞬时连接洪峰。

5. PHP 运行时与代码优化

提升单个请求的处理效率，从根本上减轻 FPM 压力。

• 启用 OPcache：这是提升 PHP 性能的“标配”。 ini opcache.enable=1 opcache.memory_consumption=128 opcache.interned_strings_buffer=8 opcache.max_accelerated_files=10000 opcache.revalidate_freq=60

• 优化资源配置：合理设置 memory_limit (如 128M-256M) 和 max_execution_time，避免资源被过度占用或过早终止。

• 代码与架构优化：

  • 优化数据库查询（索引、避免 N+1）、减少不必要的计算和文件 I/O。
  • 引入 Redis/Memcached 缓存高频访问数据和页面片段。
  • 将静态资源（图片、CSS、JS）交由 Nginx/CDN 直接处理，避免请求进入 PHP-FPM。

6. Nginx 与多实例协同

通过前端和集群分担压力。

• Nginx 配置：合理设置 worker_processes (通常等于 CPU 核心数) 和 worker_connections，并开启 Keep-alive 复用连接。
• FastCGI 缓存：对变化不频繁的接口结果进行缓存，可大幅降低 PHP-FPM 的负载。
• 多实例与负载均衡：在多台服务器上部署 PHP-FPM，并使用 Nginx 或 HAProxy 进行负载均衡，实现水平扩展。

7. 监控、压测与调优闭环

通过数据驱动持续优化，而非盲目修改配置。

• 开启状态页：配置 pm.status_path = /status，用于实时监控进程数、排队数、慢请求等关键指标。
• 日志分析：定期分析 PHP-FPM 的 slowlog 和 Nginx 的 access.log，找出性能瓶颈。
• 基准压测：使用 ab、wrk 等工具在预发布环境模拟高并发场景，观察系统指标，找到性能拐点。
• 渐进式调优：一次只修改一个关键参数，通过压测对比前后数据，逐步找到最优配置。