如何排查PHP-FPM进程CPU占用100%的间歇性问题 (2025)
更多云服务器知识，尽在hostol.com
各位服务器的“守护者”们，我们都可能遇到过这样一个令人抓狂的“幽灵”：服务器平时运行得风平浪静，岁月静好。突然，你的监控系统警报声大作，或者你只是习惯性地敲下top命令，赫然发现一个<code>php-fpm</code>进程的CPU占用率飙升到了99.9%，像一头失控的野兽，疯狂吞噬着你服务器的计算资源。你心中一紧，正准备祭出<code>strace</code>或<code>perf</code>等神器一探究竟时，它却又像一个真正的“幽灵”一样，悄无声息地消失了，CPU占用率恢复正常，仿佛什么都没发生过。几小时后，或者第二天，这个“幽行”又会毫无征兆地卷土重来。这种间歇性的、无规律出现的高CPU占用问题，无疑是服务器故障排查中最棘手的“疑难杂症”之一。它就像一个狡猾的罪犯，作案手法飘忽不定，从不留下明显的痕迹。那么，面对这个来无影去无踪的“性能杀手”，我们该如何设置“陷阱”，收集“证据”，并最终将其“捉拿归案”呢？今天，Hostol就来带你扮演一回“性能侦探”，系统化地学习如何排查一个间歇性的、无规律出现的高CPU占用PHP-FPM进程？
准备“案发现场”：开启必要的日志与工具
在我们能抓到“幽灵”之前，我们必须先确保我们的“监控摄像头”和“录音设备”是全部开启并正常工作的。被动地等待问题发生再去排查，往往为时已晚。所谓“工欲善其事，必先利其器”，我们需要提前部署好我们的“侦测网络”。
PHP-FPM的“慢日志”：捕获执行缓慢的“罪犯”
一个PHP-FPM进程长时间占用高CPU，一个非常高的可能性是它正在执行一个极其耗时、或者陷入某种死循环的PHP脚本。PHP-FPM自带的慢日志（Slow Log）功能，就是专门用来记录这些“慢动作”脚本的。这是我们最重要的线索来源。
你需要编辑你的PHP-FPM池配置文件（通常在<code>/etc/php/your-php-version/fpm/pool.d/www.conf</code>或类似路径），确保以下两个参数被开启并合理配置：
Ini, TOML
; 设置请求超时多长时间后，就记录到慢日志中。比如5秒。
request_slowlog_timeout = 5s
; 指定慢日志文件的路径。
slowlog = /var/log/php/php-fpm-slow.log
设置完毕后，别忘了重载PHP-FPM服务（例如：<code>sudo systemctl reload php-fpm</code>）使其生效。这样，任何执行时间超过5秒的PHP请求，其详细的调用堆栈信息都会被记录下来，为我们事后分析提供了宝贵的“录像”。
开启OPcache与文件状态缓存：排除低级性能问题
虽然这不直接用于抓“幽灵”，但能帮我们排除掉一些基础的性能问题。确保你的PHP开启了OPcache，并且合理配置了<code>opcache.revalidate_freq</code>等参数，可以避免PHP因为反复编译脚本文件而导致的无谓CPU消耗。这就像是确保我们的“侦探车”本身性能良好，不会因为车子自身的问题影响我们追捕。
数据库的“慢查询日志”：寻找共犯
很多时候，PHP-FPM进程本身是“无辜”的，它之所以“卡住”并消耗大量CPU，其实是因为它在苦苦等待一个执行极其缓慢的数据库查询返回结果。数据库查询，是PHP高CPU占用的最常见“共犯”。因此，务必在你的数据库服务器（如MySQL/MariaDB）上开启慢查询日志（Slow Query Log）。
例如，在MySQL的<code>my.cnf</code>配置文件中：
Ini, TOML
slow_query_log = 1
slow_query_log_file = /var/log/mysql/mysql-slow.log
long_query_time = 2
log_queries_not_using_indexes = 1
这会将所有执行时间超过2秒，以及没有使用索引的查询都记录下来。
“幽灵”再现：实时抓捕与现场勘查
万事俱备，只欠“幽灵”现身。当你的监控告警再次响起，或者你恰好通过<code>top</code>命令看到了那个CPU 100%的<code>php-fpm</code>进程时，就是我们“收网”的时刻了！动作要快，姿势要帅！
第一时间锁定“嫌疑人”：top/htop 与 ps
首先，立即在<code>top</code>或更友好的<code>htop</code>界面中，找到那个CPU占用率最高的<code>php-fpm</code>进程，并记下它的进程ID（PID）。这是我们后续所有操作的目标。
深入“嫌疑人”内心：使用 strace 跟踪系统调用
<code>strace</code>是一个极其强大的诊断工具，它能让你实时看到一个进程正在向操作系统内核发起哪些“请求”（即系统调用）。这就像是给这个进程装上了“窃听器”，它的一举一动都无所遁形。
Bash
sudo strace -p <PID>
将<code><PID></code>替换为你刚刚记下的那个进程ID。然后，你需要快速地观察屏幕上滚动的输出。寻找什么呢？
- 无休止的循环： 是否在反复地进行同样的文件读写（<code>read</code>, <code>write</code>, <code>openat</code>）？是否在疯狂地进行网络通信（<code>sendto</code>, <code>recvfrom</code>）？
- 卡在某个调用上： 屏幕是否长时间卡在某一个系统调用上没有响应？比如一个网络读取操作。
<code>strace</code>的输出能给你一个非常直观的线索，告诉你这个PHP进程在底层到底是在“忙着计算”，还是在“苦等I/O”。
(进阶) 动用“X光机”：使用 perf 进行性能剖析
如果<code>strace</code>告诉你进程是在“忙着计算”（即CPU密集型），但你不知道它在算什么，那我们就需要更专业的“X光机”——<code>perf</code>工具。<code>perf</code>是Linux内核自带的性能分析工具，能精确地告诉你CPU时间都花在了哪些函数上。
Bash
# -p 指定PID, -g 记录调用图, sleep 10 表示采样10秒
sudo perf record -p <PID> -g -- sleep 10
# 10秒后，按Ctrl+C停止采样，然后生成报告
sudo perf report
<code>perf report</code>的输出会以百分比的形式，列出消耗CPU时间最多的函数。这些函数可能来自PHP内核本身、某个PHP扩展（比如图像处理、加密库），甚至是你的PHP脚本中某个特定的函数（如果PHP配置了相关支持）。这几乎是指向问题根源的最精确的“弹道分析报告”了。
事后分析：从日志和记录中还原“作案”过程
很多时候，等我们发现问题时，“幽灵”早已消失。这时候，我们之前精心布置的“监控录像”（日志）就派上用场了。
分析PHP-FPM慢日志：找到执行过长的“元凶”脚本
这是最重要的事后分析步骤。打开你在第一步中配置的PHP-FPM慢日志文件（例如<code>/var/log/php/php-fpm-slow.log</code>）。你会看到类似这样的记录：
[28-May-2025 10:30:15] [pool www] pid 12345
script_filename = /var/www/html/some_problematic_script.php
[0x00007f...].main() /var/www/html/some_problematic_script.php:5
[0x00007f...].heavy_calculation() /var/www/html/some_problematic_script.php:25
[0x00007f...].another_function() /var/www/html/some_problematic_script.php:42
这个日志清晰地告诉了你：是哪个脚本（some_problematic_script.php）执行超时了，甚至还给出了完整的函数调用堆栈（backtrace），让你能精确地定位到可能是哪个函数出了问题。
关联Web服务器访问日志：谁是“幕后推手”？
找到了“元凶”脚本，我们还想知道是谁、通过什么操作触发了它。记下慢日志里的时间戳（比如<code>10:30:15</code>），然后去翻阅你的Nginx或Apache的访问日志（access.log）。使用<code>grep</code>命令查找那个时间点前后的访问记录。
Bash
# 在Nginx访问日志中查找
grep "28/May/2025:10:30" /var/log/nginx/access.log
你很可能会找到一条访问<code>/some_problematic_script.php</code>的请求记录，从这条记录里，你可以看到触发问题的客户端IP、请求的URL、是GET还是POST请求，以及提交的参数等。这些信息对于复现问题和理解业务逻辑至关重要。熟练地<a href="/blog/nginx-apache-log-analysis/">分析Web服务器日志</a>，是每一位运维人员的必备技能。
检查数据库慢查询日志：是否存在“共犯”？
最后，别忘了去数据库的慢查询日志里，用同样的时间戳进行关联查询。如果在那个时间点，也有一条执行了很久的SQL查询记录，那么恭喜你，“案情”基本告破！PHP进程的高CPU占用，很可能就是被这条“天长地久”的SQL查询给拖垮的。
常见“罪犯”画像与“预防”措施
通过上述的排查流程，我们通常能把问题归结为以下几种常见的“罪犯”类型：
- 代码中的无限循环或低效算法： 这是最纯粹的CPU密集型问题，比如一个嵌套了太多层的循环，或者一个算法复杂度极高的操作。需要代码开发者进行审查和优化。
- 外部API调用超时或无响应： PHP脚本中使用<code>curl</code>或其他HTTP客户端去请求一个第三方的API，但这个API响应极慢或者干脆不响应，并且你的代码里没有设置合理的超时时间。这会导致PHP-FPM进程长时间被“挂起”，虽然不一定100%占用CPU，但会占用一个宝贵的worker进程，导致整体服务能力下降。
- 数据库慢查询： 正如前面所说，这是最常见的“共犯”。一条没有索引、或者逻辑极其复杂的SQL查询，可能耗时数秒甚至数分钟，PHP进程只能傻等，有时在等待过程中也会消耗CPU。
- 文件I/O密集型操作： 在PHP脚本中对大量小文件进行循环读写，或者处理一个巨大的上传文件（比如图像缩放、视频转码），这些都可能成为CPU瓶颈。
- 正则表达式的“灾难性回溯”： 一个写得不够严谨的正则表达式，在匹配某些特定模式的、很长的字符串时，可能会陷入“回溯地狱”，导致CPU占用率瞬间飙升到100%。
- PHP-FPM自身配置不当： 虽然这不直接导致单个进程CPU 100%，但一个不合理的PHP-FPM进程管理模式（如<code>pm.max_children</code>设置过高）可能导致服务器因进程过多而资源耗尽，间接引发各种性能问题。一份合理的<a href="/blog/php-fpm-optimization/">PHP-FPM配置优化</a>方案非常重要。
常见问题解答 (FAQ)
问：我可以用gdb来调试一个正在运行的PHP-FPM进程吗？ 答：可以，但操作非常复杂，并且<code>gdb</code>会中断进程的正常运行，对于生产环境的实时排查可能并不适用。它需要你有PHP内核和Zend引擎的深入知识，以及调试符号。对于大多数场景，<code>strace</code>和<code>perf</code>是更合适的非侵入式或准侵入式诊断工具。
问：为什么我重启一下PHP-FPM服务，问题就暂时消失了？ 答：因为重启操作会杀掉所有正在运行的PHP-FPM worker进程，包括那个“卡住”的“幽灵”进程。但这只是“治标不治本”，问题根源依然存在，下一次当同样的请求或条件被触发时，“幽灵”还会再次出现。
问：这会不会是服务器硬件问题？ 答：可能性极小。单个应用程序进程的CPU 100%问题，99.99%都是由软件层面的代码逻辑、算法或外部依赖（如数据库、API）引起的。除非<code>perf</code>报告显示CPU时间大量消耗在某个可疑的内核驱动函数中，否则一般不首先考虑硬件故障。
如何排查一个间歇性的、无规律出现的高CPU占用PHP-FPM进程？这确实是一场考验耐心、细心和技术功底的“侦探游戏”。它要求我们不能只满足于“重启大法”，而是要学会提前布下“天罗地网”（开启各种日志），在问题发生时能快速、准确地使用各种“高科技”诊断工具，并在事后能像法医一样，从零散的线索中拼接出完整的“真相”。当你通过这套流程，最终揪出那个隐藏在代码深处的“性能幽灵”时，那种成就感是无与伦比的。如果你在处理这类复杂的性能问题时需要专业的协助，我们的<a href="/contact-us/">技术支持团队</a>随时准备为你提供帮助。让每一个“幽灵”都无所遁形，让我们的服务器性能始终保持在巅峰状态，这正是我们作为技术人员的价值所在。