CPU占用高怎么优化？PHP高并发调优技巧

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利用率不可能健康。

• 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进程数，只是把火从灶台引到烟囱而已。