如何调试Linux PHP-FPM问题

先说几个核心判断：PHP-FPM出问题，大多数时候不是配置写错了，就是日志没看对。如果你也曾经对着502页面一脸懵，或者发现PHP进程动不动就挂掉，那这篇东西或许能帮你少走点弯路——从排查思路到常见坑点，再到性能调优，尽量把话说明白。

一 先看看问题到底在哪儿

确认服务状态与进程

这是第一站。用 systemctl status php{version}-fpm 看服务是否在运行，再用 pgrep php-fpm 确认进程确实存在。如果发现服务没启动，别急着重启，先找它为什么起不来。

核对监听地址与端口/套接字

服务跑没跑是一回事，它到底在哪个口子等着请求，又是另一回事。用 ss -lntp | grep php 或者 netstat -plnt | grep php 看看它到底在监听什么。如果是 Unix 套接字，还得检查文件存不存在、权限对不对：ls -l /var/run/php/php{version}-fpm.sock。你猜怎么着？很多502问题就出在这——Nginx和FPM的socket对不上号。

翻系统日志

别嫌麻烦，journalctl -u php{version}-fpm -xe 能给你很多线索，比如启动失败的原因、进程崩溃的现场、甚至是谁把它重启了。

访问状态页（如果开了的话）

如果配置里启用了 pm.status_path，直接在浏览器里访问对应地址，能快速看到当前进程池的状态——有多少进程在忙、有多少在排队、有多少空闲。这可比猜靠谱多了。

重启与开机自启

改完配置，记得 systemctl restart php{version}-fpm。如果服务器重启后FPM没有自动起来，别忘了 systemctl enable php{version}-fpm。

二 日志与配置，得对得上号

日志去哪儿了？

常见路径：/var/log/php{version}-fpm.log 或者 /var/log/php-fpm/error.log。实时看用 tail -f，别等出了问题才想起来翻。

配置文件长什么样？

主配置在 /etc/php/{version}/fpm/php-fpm.conf，具体的进程池配置在 /etc/php/{version}/fpm/pool.d/www.conf。重点看几个地方：

• listen：到底是端口还是套接字？
• user 和 group：是谁在跑？
• 日志路径和日志级别：开了没？

慢日志——性能问题的照妖镜

在 www.conf 里加上这两行：

• slowlog = /var/log/php-fpm/www-slow.log
• request_slowlog_timeout = 3（单位秒）

重启后，慢日志里会直接告诉你哪个脚本、哪一行拖了后腿。这比盲猜快一万倍。

捕获脚本的输出与错误

很多时候脚本报错了，你却只看到一片空白。在 www.conf 里设置：

• catch_workers_output = yes
• php_admin_flag[log_errors] = on
• 甚至可以用 php_admin_value[error_log] 把错误单独写到一个文件里

权限与属主

确保 /var/log/php-fpm/ 和网站根目录对运行用户（通常是 www-data）可读写。套接字文件的权限常见为 0660，属主 www-data:www-data。

三 常见坑：你遇到的可能就是这些

启动失败

优先看 journalctl 和 php-fpm.log。原因不外乎：监听地址冲突、配置语法错误、日志目录不可写。如果端口被占了，换一个或者停掉占用的进程；如果套接字路径不对，修正后重启就行。

502/504 网关错误

这个最让人头疼。大概率是：

• PHP-FPM 没跑着
• 监听地址和 Nginx/Apache 配置里的 fastcgi_pass 对不上
• 权限/SELinux/AppArmor 从中作梗

检查一下 fastcgi_pass 写的是 unix:/run/php/php{version}-fpm.sock 还是 127.0.0.1:9000？和 FPM 的 listen 保持一致了吗？有时候临时关掉 SELinux 或 AppArmor 验证一下，就能确认问题是不是出在安全策略上。

权限与属主问题

网站目录和日志目录要归 www-data:www-data，权限通常 755/644。套接字需要 0660，属主也得是运行用户。

资源不够用了

进程数不够或者内存超限，都会导致 502/504 或者响应忽快忽慢。结合负载和内存情况，调整这几个参数就对了：

• pm.max_children
• pm.start_servers
• pm.min_spare_servers
• pm.max_spare_servers

另外，如果还没开 OPcache，建议马上开——效果立竿见影。

四 性能与高占用：到底谁在吃资源？

快速定位异常进程

用 top 或 htop 按 CPU 或内存排个序，或者直接用：

• ps aux --sort=-%cpu | head
• ps aux --sort=-%mem | head

几秒钟就能找到那个“吃大户”的进程。

深入系统调用与资源

找到可疑的 PID 后，可以进一步深挖：

• strace -p -T -tt -e trace=all -o fpm-strace.log —— 看它在系统调用上花了多少时间
• lsof -p —— 看它打开了哪些文件
• pmap -x —— 看内存到底分配给了什么

慢请求定位

这部分其实前面已经提到过了。慢日志是神器，找到耗时脚本和行号后，优先优化 SQL 查询、外部 API 调用、循环逻辑和缓存命中率。别一上来就怀疑CPU。

连接与超时

request_terminate_timeout、max_execution_time、pm.max_children 这几项，再加上数据库和缓存的连接池设置，必须协调好。否则一个慢请求就能触发雪崩，级联超时，整个服务直接瘫痪。

五 配置与运维：把功夫下在平时

进程管理策略怎么选？

根据负载情况选择 pm = dynamic、ondemand 或者 static。动态模式的常用参数：

• pm.max_children
• pm.start_servers
• pm.min_spare_servers
• pm.max_spare_servers

另外，设置 pm.max_requests 定期回收进程，可以缓解内存碎片和泄漏的问题。别让它无休止地跑下去。

资源与连接

提升 ulimit -n（文件描述符上限）；设置合理的 request_terminate_timeout 和 max_execution_time；数据库和缓存用连接池，并设置合理超时——这几点做好了，能避免不少“看起来很诡异”的问题。

缓存与加速

OPcache 一定要开。配置项如 memory_consumption、max_accelerated_files、revalidate_freq 调整好之后，响应速度会有肉眼可见的提升，FPM 的压力也会明显下降。

日志治理

为 error.log 和 access.log 配置 logrotate，按日轮转、压缩，避免日志把磁盘撑爆。只在排查问题时临时提高日志级别，平时保持正常即可。

监控与告警

结合 Prometheus + Grafana 或者系统自带的监控工具，持续关注进程数、排队情况、响应时延和慢请求数量。设置合理的阈值告警——等到服务挂了再去看日志，那叫救火；提前收到告警，那叫运维。