系统负载高但CPU使用率低，大概率是I/O阻塞：进程大量处于D状态等待磁盘、网络或SSL证书校验等操作完成，此时计入load却不消耗CPU；需用iostat、iotop、strace等工具定位具体瓶颈。
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 空转。
立即学习“PHP免费学习笔记（深入）”；
- 搜代码里所有
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。
运行 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 数字管用十倍。
