Ubuntu中PHP-FPM的慢日志怎么分析

在Ubuntu环境下排查PHP性能问题，PHP-FPM的慢日志绝对是最趁手的工具之一。它能把脚本卡在哪儿、哪个函数在拖后腿，直接扒开给你看。下面我们就从启用、解读到分析优化，把这条链路捋清楚。

一、启用与确认慢日志

首先找到PHP-FPM的池配置文件，常见路径是 /etc/php/{version}/fpm/pool.d/www.conf。打开后添加或修改下面两行：

• slowlog = /var/log/php-fpm/www-slow.log
• request_slowlog_timeout = 1s

这里的 1s 意味着任何执行时间超过1秒的请求都会被记录。阈值可以根据业务敏感度调整，生产环境通常从2~5秒起步。

改完后重启PHP-FPM服务，注意根据你安装的PHP版本调整服务名，例如：

sudo systemctl restart php8.1-fpm

接着用 tail -f /var/log/php-fpm/www-slow.log 确认慢日志已经开始生成并持续写入。如果没有数据，可以故意写个 sleep(10) 测试一下。

这里需要提醒一下：千万别和MySQL的慢查询日志搞混。PHP-FPM慢日志记录的是脚本执行时的函数调用轨迹，而MySQL的慢查询需要在数据库侧单独开启（slow_query_log、long_query_time）。两者是不同维度的排查手段，后续会配合使用。

二、读懂慢日志条目

一条典型的慢日志长这样：

[pool www] pid 6368
script_filename = /data/wwwroot/aminglinux.cc/test.php
[0x00007ff8c821f090] sleep() /data/wwwroot/aminglinux.cc/test.php:3

关键信息一目了然：

• pool 和 pid 标识是哪个进程池、哪个子进程出了状况。
• script_filename 直接告诉你慢的脚本是哪个。
• 下面的调用栈行以 [0x…] 函数名 文件:行号 的格式呈现，能精准定位到具体函数和代码行。上面这个例子很明显是在第3行执行了 sleep()，属于人为延时。

通过调用栈，可以快速判断瓶颈类型：如果是 curl_exec 或 file_get_contents，大概率是外部HTTP请求慢；如果是 mysql_query 或 PDO::query，则要考虑数据库层面；如果是循环内的密集计算，那就是代码优化问题。

三、常用分析方法与命令

拿到日志后，怎么从一堆数据里快速找到“元凶”？下面几个命令基本够用：

实时观察

tail -f /var/log/php-fpm/www-slow.log
适合在压测或上线后立刻盯着看，确认新改动是否引入慢请求。

按脚本汇总Top N

awk '/script_filename/ {print $3}' /var/log/php-fpm/www-slow.log | sort | uniq -c | sort -nr | head

这条命令会统计慢日志里出现次数最多的脚本文件，排在前面的就是需要优先优化的“头号嫌疑人”。

统计热点函数/文件

grep -o '\[0x[0-9a-f]*\] [^ ]*' /var/log/php-fpm/www-slow.log | sort | uniq -c | sort -nr | head

这能找出哪些函数被卡住最多，比如大量请求都堵在同一个数据库查询上。

结合系统资源排查

单纯看慢日志还不够，需要配合 top/htop 看CPU和内存占用，netstat/ss 看连接状态。如果开启了FPM状态页（pm.status_path），还可以观察进程是否在排队、空闲进程数是否合理。

深入剖析单次请求

如果慢日志里指向某个特定URL，可以用Xdebug配合Webgrind或KCacheGrind进行函数级剖析，或者用Blackfire直接出火焰图。这些工具能给出每个函数的执行时间细粒度分布，比慢日志的调用栈更详细。

数据库层面交叉验证

当怀疑数据库是瓶颈时，打开MySQL的慢查询日志（slow_query_log、long_query_time），把SQL层面的慢查询和PHP-FPM的慢日志时间点对齐，就能判断到底是SQL慢导致业务卡，还是业务逻辑本身慢。

四、从日志到优化的闭环

找到问题只是第一步，真正有价值的是把慢请求消灭掉。以下是几个最常见的根因及对应策略：

• 数据库慢查询：为高频慢SQL建立合适索引、改写查询逻辑、引入查询缓存或读写分离。很多时候加一个联合索引就能解决问题。
• 外部HTTP/API调用：设置合理的超时时间和重试机制，并发控制（比如用Guzzle的池化请求），对结果做缓存，或者考虑异步化（消息队列）。
• 计算/循环密集：优化算法与数据结构，比如把N+1查询改成批量查询，利用OPcache跳过重复编译，甚至可以用Swoole等常驻进程减少重复初始化开销。
• FPM配置不当：根据实际负载调整进程数参数——pm.max_children、pm.start_servers、pm.min_spare_servers、pm.max_spare_servers。进程太多会耗尽内存，太少又会造成请求排队等待。

优化完成后，需要验证和回归。一个常用的做法是：把慢日志阈值从5秒逐步降低到1秒，然后观察慢日志数量是否显著下降，同时监控P95/P99响应时间。如果这些指标稳住了，说明优化有效。持续监控，才能让性能不会随着时间推移重新变差。