Ubuntu PHP日志中的超时问题定位与解决
一、先定位超时的类型与层级
- 查看 PHP-FPM 错误日志 与 慢日志：
- 慢日志能直接指出“哪一行代码/哪个调用”慢：在 /etc/php/7.x/fpm/pool.d/www.conf 中开启
- request_slowlog_timeout = 1s（超过 1 秒的请求记录堆栈）
- slowlog = /var/log/php-fpm/www-slow.log
- 重启生效：sudo systemctl restart php7.x-fpm；实时排查：tail -f /var/log/php-fpm/www-slow.log。
- 查看 Nginx 错误日志（/var/log/nginx/error.log）：若出现 “upstream timed out (110: Connection timed out) while reading response header from upstream”，说明网关与 FPM 之间的 FastCGI 读超时 过短。
- 查看 PHP 错误日志（由 php.ini 的 error_log 指定）：确认是 max_execution_time 触发，还是 FPM request_terminate_timeout 终止。
- 注意层级关系：在 PHP-FPM 模式下，真正强杀脚本的通常是 request_terminate_timeout；而 max_execution_time 在 FPM 场景可能不生效或仅影响部分执行路径。
- 若是 CLI 任务，默认 无执行时间限制，需用 set_time_limit() 或命令行参数控制。
二、常见超时场景与对应配置
| 场景 |
关键日志特征 |
建议调整 |
备注 |
| PHP 脚本执行超时 |
PHP 错误日志出现 “Maximum execution time of X seconds exceeded” |
在 php.ini 调大 max_execution_time（如 300）；或在脚本中用 set_time_limit(300)；同时确认 max_input_time 足够 |
仅对当前请求有效；CLI 默认无限制 |
| FPM 请求被强杀 |
FPM 错误日志出现 “request_terminate_timeout” 触发 |
在 www.conf 设置 request_terminate_timeout = 300（或更长）；设为 0 表示不主动终止（风险自担） |
强杀可能导致 502/104；更推荐优化代码而非一味加时 |
| Nginx ↔ FPM 网关超时 |
Nginx 错误日志 “upstream timed out … while reading response header” |
调大 fastcgi_read_timeout 300；必要时也调 fastcgi_send_timeout / fastcgi_connect_timeout |
需与 FPM 的 request_terminate_timeout 协调 |
| 进程不够或频繁重启导致 502 |
FPM 日志间歇性 “unable to fork” 或 “child exited on signal 11” |
调整 pm.max_children / pm.start_servers / pm.min_spare_servers / pm.max_spare_servers；适当增大 pm.max_requests 减少内存泄漏带来的抖动 |
结合内存与并发评估，避免频繁 spawn |
| 外部 HTTP/DB/Redis 调用阻塞 |
慢日志指向 file_get_contents/curl/PDO 等调用 |
为 cURL 设置 CURLOPT_TIMEOUT / CONNECTTIMEOUT；为 file_get_contents 使用 stream context timeout；为 PDO 设置 ATTR_TIMEOUT；为 default_socket_timeout 设合理值 |
避免同步等待外部资源拖垮进程 |
上述配置项与含义、生效范围及相互影响，可参考 PHP 与 FPM 官方常用参数与实践经验。
三、推荐的排查与修复流程
- 复现与抓取证据：在高峰期复现，实时 tail PHP-FPM 慢日志 与 Nginx 错误日志，记录触发超时的 URL/参数/时间点/进程 ID。
- 先查慢日志定位瓶颈：慢日志会打印 调用栈与文件行号，优先优化这些热点路径（SQL、外部 API、循环与算法）。
- 分层对齐超时：确保 Nginx fastcgi_read_timeout ≥ FPM request_terminate_timeout ≥ PHP max_execution_time，避免“上层先断、下层还在跑”。
- 优化外部依赖：为 HTTP/DB/Redis 调用统一加上连接与总超时，并对慢查询做索引与语句优化；必要时引入 缓存（OPcache、Redis）。
- 控制并发与稳定性：按内存与 QPS 调整 pm. 与 pm.max_requests*，减少进程频繁重建导致的 502。
- 持久化与回归：修改后先灰度，观察 错误率、95/99 延迟、吞吐 是否改善，再全量发布。
四、关键配置示例
- PHP-FPM 慢日志（/etc/php/7.x/fpm/pool.d/www.conf）
- request_slowlog_timeout = 1s
- slowlog = /var/log/php-fpm/www-slow.log
- 重启：sudo systemctl restart php7.x-fpm
- PHP 执行时间（php.ini）
- max_execution_time = 300
- max_input_time = 300
- Nginx FastCGI（/etc/nginx/sites-available/your-site）
- fastcgi_read_timeout 300; fastcgi_send_timeout 300; fastcgi_connect_timeout 300;
- 代码层超时示例
- cURL：curl_setopt($ch, CURLOPT_TIMEOUT, 15); curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 10);
- file_get_contents：
- $ctx = stream_context_create([‘http’=>[‘timeout’=>10]]); file_get_contents($url, false, $ctx);
- PDO：new PDO($dsn, $user, $pass, [PDO::ATTR_TIMEOUT => 30]);
- 脚本内：set_time_limit(300);
以上示例覆盖了定位与修复超时最常用的配置与代码手段，可直接按需套用并配合日志验证效果。
