PHP-FPM慢日志配置必须写在pool文件（如www.conf）中，而非php-fpm.conf；需同时设置request_slowlog_timeout（如1s）和slowlog（如/var/log/php-fpm/www-slow.log），且取消分号注释、确保路径权限匹配运行用户，再通过sleep测试脚本和tail命令验证日志输出。
确认当前生效的 pool 配置文件位置
PHP-FPM 的慢日志配置必须写在 pool 文件里（比如 www.conf），不是主配置 php-fpm.conf。直接改错地方会导致配置完全不生效。
先查你实际用的是哪个 pool：
ps aux | grep php-fpm
看到类似 php-fpm: pool www，就说明生效的是 www 这个池；如果显示 pool app，那就要去改 app.conf。
常见路径（按发行版区分）：
立即学习“PHP免费学习笔记（深入）”；
- RHEL/CentOS：/etc/php-fpm.d/www.conf
- Ubuntu/Debian：/etc/php/8.x/fpm/pool.d/www.conf（把
8.x换成你的真实版本，如8.2）
别猜路径，用 find /etc -name "*.conf" | xargs grep -l "\[www\]" 快速定位。
开启 slowlog 的两个必要参数缺一不可
request_slowlog_timeout 和 slowlog 必须同时启用，且不能只取消注释——还要确保值合法。
典型错误配置：
- 只开
request_slowlog_timeout = 1，但没配slowlog→ 日志不写，也不报错，静默失效 -
slowlog路径父目录不存在 → PHP-FPM 启动时不会报错，但日志写不进去，tail -f看不到任何内容 -
request_slowlog_timeout = 0或留空 → 慢日志功能关闭（默认就是 0）
正确写法（加在 pool 段内，例如 [www] 下面）：
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
request_slowlog_timeout = 1s<br>slowlog = /var/log/php-fpm/www-slow.log
注意：1s 是带单位的字符串，不能写成 1；路径需提前创建目录并确保 PHP-FPM 进程用户（如 www-data 或 nginx）有写权限：
sudo mkdir -p /var/log/php-fpm<br>sudo chown www-data:adm /var/log/php-fpm<br>sudo chmod 0755 /var/log/php-fpm
验证慢日志是否真正在记录
重启后不等于就生效了。要确认三点：
- PHP-FPM 是否成功加载新配置：运行
sudo systemctl reload php8.2-fpm（版本号对齐），不要用restart，避免意外中断请求 - 慢日志路径是否有写入权限：用
sudo -u www-data touch /var/log/php-fpm/www-slow.log测试 - 有没有真实触发慢请求：写一个测试脚本
/var/www/html/slowtest.php：
<?php<br>sleep(2);<br>echo "done";<br>?>
然后用 curl http://localhost/slowtest.php 访问。如果阈值设的是 1s，这次请求就会进慢日志。
查看日志内容，正常应类似：
[02-Oct-2026 17:25:33] [pool www] pid 12345 script_filename = /var/www/html/slowtest.php [0x00007f8b1c0a9e20] sleep() /var/www/html/slowtest.php:2
如果日志为空，优先检查 journalctl -u php8.2-fpm -n 30，常见提示如 WARNING: [pool www] child 12345, script '...' executing too slow (1.234567 sec), logging 就说明已捕获，只是日志没写出去——大概率是权限或路径问题。
慢日志里关键字段怎么看
日志每行不是纯时间戳+路径，真正有用的是栈帧部分：
-
script_filename：入口 PHP 文件，但不一定是瓶颈点 - 方括号里第一个函数（如
sleep()、curl_exec()、mysqli_query()）是超时发生时正在执行的函数，大概率就是卡点 - 后面跟着的调用链（如
exfilter_curl_get()）说明这个慢函数是谁调出来的，帮你定位到业务层代码位置 - 冒号后的数字（如
:2）是该函数调用所在的源码行号，比靠猜快得多
注意：如果看到 fopen() 或 file_get_contents() 卡住，大概率是远程 HTTP 请求没设超时；如果全是 mysqli_query()，先看对应 SQL 是否缺少索引或锁表——慢日志只告诉你“在哪卡”，不解释“为什么卡”，得结合 MySQL 的 slow_query_log 或 SHOW PROCESSLIST 继续追。
路径和权限问题最容易被跳过，但恰恰是 80% 的配置失败原因；栈帧里的函数名和行号看着琐碎，却是定位真实瓶颈最省时间的线索。
