PHP-FPM slowlog 怎样定位慢请求

PHP-FPM slowlog 的定位思路不是“看到一条慢日志就改超时”，而是先让正确的 pool 生成 PHP 回溯，再把回溯里的脚本、函数和等待边界与 FPM 状态、应用请求日志对上。这样能回答两个问题：慢在哪里，以及它是否真的属于同一批慢请求。

官方地址：https://www.php.net/install.fpm.configuration

一、先把 slowlog 配置到正确的 PHP-FPM pool

PHP-FPM 的全局配置和 pool 配置不是一回事。常见部署里，真正承载 Web 请求的是类似 www 的 pool，因此排查时要先确认正在编辑的文件确实被主配置包含。slowlog 最关键的三个参数如下：

; 仅示例：把配置放在实际接收请求的 pool 中
request_slowlog_timeout = 3s
; 使用明确路径，便于与日志采集规则对应
slowlog = /var/log/php-fpm/www-slow.log
; 先保留默认深度，只有回溯不够时再增加
request_slowlog_trace_depth = 20

改完后先做配置语法检查，再按发行版方式平滑重载。这里不要直接把阈值设成极小值：慢日志会快速膨胀，也可能让正常的短暂外部等待淹没真正异常。

二、从慢日志堆栈还原慢请求位置

slowlog 写出的核心价值是 PHP backtrace，而不是只有一个脚本名。读取时先按时间段截取一组完整记录，再看入口脚本、当前函数和重复出现的调用边界。若多条记录都停在同一个数据库访问封装或 HTTP 客户端调用附近，优先把它当作等待点继续核对；不要仅凭最顶层文件名修改业务代码。

# 只读取最近一段记录，避免把历史噪声混进当前排查
sudo tail -n 120 /var/log/php-fpm/www-slow.log

# 先确认文件存在、属主和权限，再判断是否真的没有生成回溯
sudo stat /var/log/php-fpm/www-slow.log
sudo journalctl -u php-fpm --since "10 minutes ago"

一次慢请求可能在阈值附近产生回溯，但回溯本身不等于“这行代码就是根因”。把记录中的脚本路径、函数名和时间，与 Web 访问日志的 URL、状态码、耗时以及应用日志里的 request id 对齐，才能知道它是否对应同一个请求。

三、用 FPM 状态与应用日志交叉确认

如果 pool 开启了状态页，可以关注 slow requests、活动进程和等待队列等字段。slow requests 表示命中 request_slowlog_timeout 的请求累计数，它能帮助判断“慢日志是否在增长”，但不能单独告诉你是哪一个 URL 慢。

排查时建议建立一个很小的对照表：slowlog 记录时间对应 Web access log 的请求时间；入口脚本对应路由；回溯中的依赖调用对应应用日志的 request id；状态页的累计值只用于判断趋势。若 slowlog 有内容而应用日志没有对应请求，先检查时区、日志缓冲和采集延迟。

四、常见问题与发布检查

为什么改了配置却没有 slowlog 文件？

最常见是改错 pool、主配置没有 include 该文件，或日志目录对 FPM worker 不可写。先从正在运行的 FPM 配置和服务日志确认加载结果，再查目录权限。

request_slowlog_timeout 会杀掉慢请求吗？

不会。它的职责是达到阈值后写 PHP 回溯；需要终止 worker 请求时，应单独评估 request_terminate_timeout，并确认这会带来什么回滚和数据一致性影响。

slowlog 阈值应该设多少？

按接口的正常耗时分布设一个能抓住异常、又不会制造海量日志的临时阈值。定位结束后恢复到团队约定，并保留一次配置变更记录。

发布前只需复核四项：配置落在正确 pool、日志路径可写、慢日志能与请求日志按时间或 request id 对齐、终止超时没有被误当成 slowlog。这样得到的才是一条可复查的慢请求定位链路。