php7.2-fpm出现(polling)指定超时已过期错误如何排查并永久修复

你给出的Apache错误日志属于典型的反向代理调度请求到php-fpm时超时报错，核心原因是php-fpm无法及时响应请求、或无法接收新的请求。

根因排查步骤 #

• 首先检查php-fpm错误日志，默认路径为/var/log/php7.2-fpm.log，重点核对宕机时间点前后的日志内容，确认是否存在max_children上限触发、进程僵死、内存溢出相关的报错。
• 开启php-fpm状态页，配置完成后通过curl http://127.0.0.1/php-fpm-status查询运行指标，重点关注max children reached（达到最大子进程数的累计次数）、listen queue（请求监听队列积压数）、slow requests（慢请求数量）三个核心指标。如果max children reached数值持续增长，说明子进程配置不足，或者有请求长时间占用进程不释放。
• 开启php-fpm慢请求日志，在php-fpm主配置中设置request_slowlog_timeout = 3s，slowlog = /var/log/php7.2-fpm-slow.log，收集超过3秒的请求调用栈，定位是否存在死循环、数据库慢查询、外部接口调用无超时限制的问题，这类问题会长期占用php-fpm进程，导致新请求无法分配到可用进程，最终触发Apache超时。
• 核对近期业务变动记录，确认故障出现的时间点是否匹配新功能上线、第三方依赖更新、数据库配置调整的时间，近一个月才首次出现的故障绝大多数和业务侧变动相关。
• 排查宕机时间点的服务器资源占用，通过sar、top历史记录或监控数据核对CPU、内存、SWAP占用情况，确认是否存在内存占满触发OOM杀掉php-fpm进程的情况。

永久修复方案 #

• 调整php-fpm进程配置：如果确认是子进程数不足，根据服务器剩余可用内存调整pm.max_children参数（单个php-fpm进程通常占用30-80M内存，按「剩余可用内存/单进程平均内存」计算合理上限），同步调整pm.start_servers、pm.min_spare_servers、pm.max_spare_servers匹配日常访问量，避免进程频繁销毁重建。如果请求监听队列存在积压，适当调大listen.backlog参数。
• 修复业务侧问题：根据慢日志定位到的异常请求优化代码，给数据库查询加索引、给外部接口调用加超时限制，避免无限制占用进程。如果存在代码内存泄漏的问题，可以设置pm.max_requests参数，让php-fpm进程处理完指定数量的请求后自动重启，主动释放占用的内存。
• 适配超时配置：如果有正常的长请求（如大文件导出、批量数据处理）需要更长的执行时间，可同步调整Apache的ProxyTimeout参数和php的max_execution_time参数，两侧超时时间保持一致，避免Apache提前断开请求。
• 升级PHP版本：PHP7.2已经停止官方维护，存在未修复的底层BUG，如果排查后确认是php-fpm本身的进程管理缺陷导致的故障，可以升级到更高的LTS版本（如PHP7.4、PHP8.1），从底层解决稳定性问题。

内容的提问来源于stack exchange，提问作者John Crawford