PHP-FPM进程显示Sleep却CPU高，多因top采样误差或I/O等待、锁竞争所致；应使用pidstat分析上下文切换与磁盘等待，检查OPcache配置、SQL索引、N+1问题及是否该迁移到Swoole协程。
PHP-FPM进程Sleep却占CPU？先别急着调代码
看到top里一堆php-fpm进程状态是S（Sleep），但%CPU还飙到30%，第一反应常是“代码卡住了”——其实大概率不是。Linux的%CPU统计是采样瞬间值，top自身抓取进程信息时就可能触发内核调度，让本在休眠的进程被临时唤醒参与调度，造成“假高占用”。真瓶颈往往藏在I/O等待或锁竞争里。
- 用
pidstat -u -w -d 1替代top：它能分开看CPU使用率、上下文切换次数（cswch/s）和磁盘I/O等待（await） - 若
cswch/s异常高（比如 > 10k），说明进程频繁切换，大概率是FPM子进程数过多或协程未合理复用 - 若
await持续 > 10ms，重点查MySQL慢查询、Redis连接阻塞、或本地文件读写（如未关闭的fopen()日志句柄）
OPcache没开或参数太保守，等于裸跑PHP
PHP每次请求都要重解析、编译脚本，这部分开销在高并发下会被急剧放大。OPcache不是“开了就行”，默认配置对中大型项目几乎无效。
-
opcache.memory_consumption=128→ 至少调到256（单位MB），小项目可192，但别低于128 -
opcache.max_accelerated_files=4000→ 必须大于你项目实际PHP文件数（find ./ -name "*.php" | wc -l），建议设为20000 -
opcache.revalidate_freq=2→ 开发环境可设为0（实时检测变更），生产环境设60秒足够，设0会引发大量stat系统调用，反拖慢CPU - 确认生效：
php -i | grep opcache看opcache.enable => On且opcache.huge_code_pages => Off（开启huge pages需内核支持，否则反而降速）
数据库查询没加索引 + N+1，CPU全在等磁盘
CPU占用高，很多时候是PHP进程在同步等待MySQL返回结果。一个没走索引的SELECT * FROM orders WHERE user_id = ?，扫表几百万行，CPU不飙才怪。
- 用
EXPLAIN检查所有高频SQL，特别警惕type=ALL（全表扫描）和rows远大于实际返回数 - N+1问题典型场景：
foreach ($users as $u) { $profile = $pdo->query("SELECT * FROM profiles WHERE uid = {$u['id']}"); }→ 改成单次JOIN或预加载 - 避免在循环里执行
file_get_contents()、curl_exec()等阻塞IO，它们会让整个PHP进程挂起，CPU空转等超时 - 用
PDO::ATTR_EMULATE_PREPARES = false强制走MySQL原生预处理，减少PHP层SQL拼接开销
该上Swoole的地方硬扛FPM，CPU就是干烧
当QPS稳定超过500，还在用PHP-FPM + Nginx同步模型，相当于让快递员每次送一单都回总部打卡再出发——架构层面就决定了CPU利用率不可能健康。
立即学习“PHP免费学习笔记（深入）”；
- FPM本质是“每请求一进程”，1000并发 ≈ 1000个PHP进程，内存和上下文切换吃掉大量CPU
- Swoole协程模式下，1个Worker进程可并发处理数千请求，I/O等待时自动让出CPU，真正压榨多核
- 迁移关键点：把
mysql_query()换成Swoole\Coroutine\MySQL，file_get_contents()换成Co\Http\Client，PDO要换co\run()包裹 - 注意陷阱：协程非线程安全，全局变量、静态变量、
sleep()、exit()都会破坏协程调度，必须重构
高并发下的CPU优化，从来不是调几个php.ini参数就能解决的事。真正卡点往往在“哪里不该用同步”——比如库存扣减还在用事务+SELECT FOR UPDATE硬扛，而没切到Redis原子操作；比如日志写入还在fopen()追加，而不是推到消息队列异步落盘。这些地方不动，光压PHP版本或调FPM进程数，只是把火从灶台引到烟囱而已。
