如何排查ubuntu上php-fpm的慢查询

在线上运维中，PHP-FPM慢查询是常见的性能问题，但排查起来往往让人摸不着头脑——是代码逻辑太慢，还是数据库拖了后腿？别急，下面从日志配置、实时监控到深度优化，把整个排查流程掰开揉碎，一步一步说清楚。

如何排查Ubuntu上PHP-FPM的慢查询

1. 启用PHP-FPM慢查询日志

要定位PHP脚本执行慢的问题，慢查询日志是最直接的工具。需要修改PHP-FPM池配置文件，通常位于/etc/php/{version}/fpm/pool.d/www.conf（注意替换{version}为实际版本，如7.4、8.1）。关键参数如下：

; 开启慢日志并指定路径（确保目录存在且有写入权限）
slowlog = /var/log/php-fpm/www-slow.log
; 设置慢查询阈值（单位：微秒，如1秒=1000000微秒）
request_slowlog_timeout = 1000000
; 记录慢查询的调用堆栈深度（可选，用于更详细的分析）
slowlog_max_stack_trace_lines = 20

修改后重启PHP-FPM使配置生效：

sudo systemctl restart php{version}-fpm

2. 实时查看慢查询日志

配置好了，怎么盯住它？用tail命令实时监控慢日志输出，可以快速定位当前慢请求：

sudo tail -f /var/log/php-fpm/www-slow.log

日志内容通常包含执行时间、请求URI、调用堆栈（如涉及的函数、文件）。举个例子：

[27-Sep-2025 10:00:00] WARNING: [pool www] child 12345, script '/var/www/html/index.php' (request: "GET /api/orders") execution timed out (1.23456 sec), logging to '/var/log/php-fpm/www-slow.log'
[stack trace]
#0 /var/www/html/index.php(45): PDO->query('SELECT * FROM or...')
#1 /var/www/html/api/orders.php(12): getOrderController->getOrders()

看到堆栈里的PDO->query，基本就能把矛头指向数据库查询了。

3. 分析慢日志（命令行工具）

日志量大了以后，手动翻看效率太低。可以用命令行工具快速提取关键信息：

• 统计慢请求频率：找出最常出现的慢请求路径或IP。

  # 统计每个请求URI的慢查询次数（按次数降序）
  grep 'script' /var/log/php-fpm/www-slow.log | awk '{print $6}' | sort | uniq -c | sort -nr | head -10
  # 统计每个客户端的慢查询次数（按次数降序）
  grep 'REMOTE_ADDR' /var/log/php-fpm/www-slow.log | awk '{print $2}' | sort | uniq -c | sort -nr | head -10

• 提取慢请求详情：查看具体慢请求的堆栈信息。

  # 提取包含特定URI（如/api/orders）的慢日志
  grep '/api/orders' /var/log/php-fpm/www-slow.log

4. 关联数据库慢查询日志

PHP慢查询十有八九跟数据库操作有关，所以得同步开启MySQL/MariaDB的慢查询日志，双管齐下才能定位慢SQL：

• 修改MySQL配置（/etc/mysql/mysql.conf.d/mysqld.cnf）：

  [mysqld]
  slow_query_log = 1
  slow_query_log_file = /var/log/mysql/slow-query.log
  long_query_time = 1; 设置慢SQL阈值为1秒
  log_queries_not_using_indexes = 1; 记录未使用索引的查询

• 重启MySQL并分析慢日志：

  sudo systemctl restart mysql
  # 使用mysqldumpslow分析慢SQL（按执行时间排序）
  mysqldumpslow -s t /var/log/mysql/slow-query.log
  # 或使用pt-query-digest（需安装Percona Toolkit）
  pt-query-digest /var/log/mysql/slow-query.log

5. 使用性能分析工具深入排查

如果慢日志和慢SQL日志都查了，还是找不到瓶颈，那就得请出更专业的工具了：

• Xdebug：生成函数级性能分析报告，查看代码执行时间分布。

  # 安装Xdebug
  sudo apt install php-xdebug
  # 修改php.ini（/etc/php/{version}/fpm/php.ini）
  zend_extension=xdebug.so
  xdebug.mode=profile
  xdebug.output_dir=/tmp/xdebug
  # 重启PHP-FPM后，访问页面会在/tmp/xdebug生成分析文件

• Blackfire：商业性能分析工具，提供可视化报告（支持函数调用树、内存占用分析）。
• Webgrind：轻量级Web界面，解析Xdebug生成的profile文件，展示性能瓶颈。

6. 优化PHP-FPM配置

日志分析完了，该动手优化了。根据服务器资源调整PHP-FPM进程参数，避免进程过多或过少导致的性能问题：

; 进程管理方式（动态调整更适合大多数场景）
pm = dynamic
; 最大子进程数（根据CPU核心数调整，如4核可设为20）
pm.max_children = 20
; 启动时的子进程数（建议为max_children的1/4）
pm.start_servers = 5
; 最小空闲子进程数（避免频繁创建进程）
pm.min_spare_servers = 5
; 最大空闲子进程数（避免占用过多内存）
pm.max_spare_servers = 10
; 请求完成后终止进程（避免内存泄漏）
pm.max_requests = 500

修改后重启PHP-FPM：

sudo systemctl restart php{version}-fpm

7. 其他优化措施

• 启用OPcache：缓存编译后的PHP脚本，减少重复解析时间。

  ; 修改php.ini（/etc/php/{version}/fpm/php.ini）
  zend_extension=opcache.so
  opcache.enable=1
  opcache.memory_consumption=128
  opcache.interned_strings_buffer=8
  opcache.max_accelerated_files=4000

• 使用缓存：对频繁访问的数据库查询结果使用Redis/Memcached缓存，减少数据库负载。
• 异步处理：将耗时任务（如发送邮件、生成报表）放入消息队列（如RabbitMQ、Redis），避免阻塞PHP进程。

以上步骤从日志配置、实时监控、深度分析到配置优化，基本覆盖了Ubuntu上PHP-FPM慢查询的排查全流程。遇到性能问题，按这个思路一步步来，大多能定位到根因。