为什么PHP环境下的系统负载异常高_使用top和strace追踪FPM进程-php教程-PHP中文网

系统负载高但cpu使用率低，大概率是i/o阻塞：进程大量处于d状态等待磁盘、网络或ssl证书校验等操作完成，此时计入load却不消耗cpu；需用iostat、iotop、strace等工具定位具体瓶颈。

为什么php环境下的系统负载异常高_使用top和strace追踪fpm进程

top里load高但%CPU低，大概率是I/O卡住了

系统负载（load average）高 ≠ CPU被占满。当top显示 load 10+ 而所有 php-fpm 进程的 %CPU 加起来才 20%，说明大量进程正堵在 I/O 上——比如磁盘读写、网络等待、或 SSL 证书校验失败导致的阻塞。

立刻执行：iostat -x 1 5，重点看 %util 是否持续 >90%、await 是否 >50ms；再跑 iotop -o，揪出 IO 最猛的那个 php-fpm 进程 PID。

若 iotop 显示某 php 进程在反复读 /etc/ssl/certs/ca-certificates.crt 或类似路径，但文件不存在 → 很可能是 curl 或 elasticsearch 客户端用 https 却找不到 CA 包，陷入重试循环
若 strace -p [pid] -e trace=open,openat,read 暴露大量 open("/path/to/missing/file") = -1 ENOENT，基本坐实路径配置错误
别急着改代码：先确认是 http 还是 https 调用，临时切 http 测试是否负载回落

strace -c 显示 rt_sigprocmask 占比超高，小心 pcntl tick 配置

strace -c -p [pid] 结果里如果 rt_sigprocmask 出现次数远超其他系统调用（比如占比 40%+），不是内核问题，而是 PHP 自身信号处理机制被高频触发——根源常在 pcntl 扩展 + 不当的 declare(ticks=1)。

这种组合会让 PHP 每执行 1 条底层指令就调用一次信号分发函数，而该函数内部反复调用 rt_sigprocmask 屏蔽/恢复信号，纯属 CPU 空转。

搜代码里所有 declare(ticks=，尤其关注 pcntl_signal_dispatch() 调用附近
ticks 值设为 1 是最危险的，生产环境应避免；如必须用 tick，至少设为 100 或更高
替代方案：用 pcntl_async_signals(true)（PHP 7.1+）代替 tick 机制，信号可异步响应，不拖慢主流程

php-fpm 进程数爆炸但单个 CPU 占用低，检查 pm 配置和内存水位

当 top 里出现几十个 php-fpm: pool www 进程，每个 %CPU 只有 5–10%，但 load average 压到 20+，说明进程调度已严重失衡——常见于 pm.max_children 设得太大，而物理内存不足，导致频繁 swap 或上下文切换开销反噬 CPU。

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

运行 ps aux --sort=-%mem | grep php-fpm | head -5 看单个进程常驻内存（RSS），再结合 free -h 判断是否逼近内存上限。

若 SwapUsed > 0 且持续波动 → 内存真不够，优先调小 pm.max_children，而非加机器
pm = ondemand 在流量突增时会疯狂 fork 新进程，fork 本身耗 CPU；换成 pm = dynamic 并合理设置 pm.start_servers 和 pm.min_spare_servers
检查 pm.max_requests 是否过小（如设为 100），导致进程频繁重启，积累 fork 开销

slowlog 没记录但 CPU 一直高，可能卡在扩展或系统调用里

开启 slowlog 后没捕获到慢请求，不代表没问题。有些高 CPU 场景根本不走 PHP 用户态：比如 xdebug 未关闭（即使没打断点）、opcache 验证时间戳开启、或 curl_easy_perform 卡在 DNS 解析/SSL 握手。

用 strace -tt -T -p [pid] 观察真实耗时点，重点关注 epoll_wait（等待事件）、poll（轮询描述符）、read（读取数据）这三类调用的 <...></...> 时间值。

若 epoll_wait 返回时间极短但调用频率极高 → 可能是空轮询，检查是否用了不兼容的 event loop 库
若 read 长时间阻塞在某个 fd 上 → 用 lsof -p [pid] 查该 fd 对应的文件或 socket，确认是数据库连接、Redis 还是外部 API
确认 opcache.validate_timestamps=0 和 xdebug.mode=off 已生效，这两项关不掉，CPU 就永远虚高一截

真正难缠的高负载，往往藏在「看起来正常」的系统调用里——比如证书路径错、tick=1、或 pm.max_children 和内存不匹配。这些地方不会报错，但会让服务器在临界点反复抖动。盯住 strace -c 的占比分布，比只看 top 数字管用十倍。