很多做 PHP 的朋友应该都遇到过这样一个场景：公司终于给了一台 16 核的服务器，你兴冲冲把项目部署上去，结果 top 一看，CPU 使用率只有 5%，可业务量稍微一上来，页面就开始卡。又或者反过来，某个脚本一跑 CPU 直接飙满，但 QPS 还是上不去。于是大家就会问：PHP 到底怎么做，才能把这 16 个核心真正用起来？
这篇文章我不打算讲 PPT 上那些云里雾里的概念，就从 PHP-FPM 的进程模型说起，把并发、异步、消息队列、数据库瓶颈、压测排查这些环节全部串一遍。最后你会得到一份可以照着改的优化清单。无论你是正在被老板催着做性能优化，还是想把单机 PHP 项目改造成更高并发，这篇文章都适合你。
1. 先搞清楚：PHP 的“CPU 利用率”到底卡在哪
1.1 一个请求一趟“流水线”，绝大部分时间在等待
PHP-FPM 模式下一个请求的完整路径大概是这样的：Nginx 收到 HTTP 请求，通过 FastCGI 协议交给 php-fpm；php-fpm 从进程池里拿一个空闲 worker；worker 开始编译、执行 PHP 脚本。脚本里大概率会查 MySQL、读 Redis、调外部 HTTP 接口，最后拼装数据返回给 Nginx。
关键点在于：CPU 只在这个过程中真正“干活”的一小段。解析 PHP 脚本是 CPU 干活，循环、排序、加密、处理业务数据是 CPU 干活；但等数据库返回、等 Redis 返回、等外部接口返回的时候，CPU 其实是在“空转等待”。一次请求耗时 300ms，可能其中只有 10ms 是 CPU 在执行指令，剩下 290ms 都在等 I/O 完成。
所以你会看到一种很奇怪的现象：16 核机器 CPU 使用率只有个位数，但页面还是慢得像蜗牛。这不是 CPU 不够，而是大量请求都堵在“等待”环节。用个生活化的比喻：16 个厨师已经站在后厨了，但客人点的菜大部分还在食材供应商那边送货，厨师再厉害也只能等着。
1.2 16核服务器只跑满一个核，问题通常不是 CPU 不够
如果你发现 16 个核里只有 1 个核 100%，其他 15 个核都是 0%，先别急着加机器。这个现象背后大概率是几个原因：要么 php-fpm 进程数太少，请求根本没有足够的进程来处理；要么代码里有某个全局锁、文件锁、单例连接，把整个业务的并发能力压成了串行；要么你跑的是一个常驻的单进程脚本，比如自己写的 daemon，天然只能用上单核。
很多年前我做过一个后台任务系统，脚本里有个文件锁，每次只能有一个进程去处理任务。后来任务量涨了，我开了 16 个进程去跑，结果 CPU 还是只有一个核在动，其他进程全部卡在等锁上。检查之后把文件锁改成 Redis 分布式锁并做了分片，才把并发真正拉起来。
1.3 先量化，再优化：uptime、mpstat、pidstat 怎么看
拿到一台机器，第一步不是改代码，而是先看清 CPU 到底花在哪。我一般会按下面这套命令扫一遍：
uptime mpstat -P ALL 1 pidstat -u 1 top -Hp $(pgrep -f php-fpm | head -1)uptime看 load average，mpstat -P ALL看每个核心的使用率，pidstat看每个进程的 CPU 占比。如果%iowait很高，优先排查磁盘和数据库；如果某个 php-fpm 进程 CPU 长期 100%，就要去看这个 worker 正在执行什么代码。
| 指标 | 看什么 | 判断方向 |
|---|---|---|
| load average | 系统整体负载 | 高负载 + 低 CPU 空闲，可能是 I/O 阻塞 |
| %iowait | CPU 等待 I/O 的时间 | 高 -> 慢查询、磁盘、网络 |
| %user | 用户态 CPU 时间 | 高 -> 代码本身是 CPU 密集 |
| 单个 worker CPU | 是否集中在某一进程 | 单进程瓶颈 or 锁竞争 |
2. 机器有16个核，PHP-FPM到底能开多少个进程
2.1 pm.max_children 不是越大越好
很多人的第一反应是：16 核嘛，开 16 个进程不就正好？这种想法对了一半。进程数少了，CPU 确实吃不饱；但进程数太多了，CPU 大量时间花在进程切换上，吞吐量反而会下降。
进程数的上线主要看内存。每个 php-fpm-worker 都会占用一部分内存，简单业务可能 20-30MB，复杂业务 80-100MB 很正常。假设一台 16 核机器有 32GB 内存，MySQL、Redis 等基础服务占了 8GB，然后每个 php-fpm 平均 60MB，那么理论上 max_children 可以开到 (32GB - 8GB) / 60MB ≈ 400 左右。但问题来了：16 核机器上开 400 个进程，如果是 CPU 密集型业务，每个进程都在抢 CPU 时间片，调度开销非常恐怖。如果是 I/O 密集型业务，开多一些进程确实能掩盖等待时间，但也不是越多越好。
我的经验是：先区分业务类型。CPU 密集型，比如批量加密、图像处理、复杂计算，进程数往核心数靠，16 核就 16-32 个；I/O 密集型，比如大部分 Web 接口，进程数可以适当放大，从 64 开始压测，看哪个点 QPS 最高。
2.2 一套可以用的计算方法和配置模板
下面这套配置是我常用的起点，注意只是起点，不是最终答案：
pm = dynamic pm.max_children = 64 pm.start_servers = 16 pm.min_spare_servers = 8 pm.max_spare_servers = 32 pm.max_requests = 5000dynamic模式的好处是能根据流量自动调整 worker 数量，比较适合流量波动大的场景。如果你追求稳定、不想让 php-fpm 频繁 fork/回收进程，也可以直接pm = static，把pm.max_children固定在一个值。我个人的偏好是：内存充裕、流量相对稳定时用 static，效果更可预测。
pm.max_requests这个参数很多人会忽略。它可以让每个 worker 处理完一定数量的请求后自动退出重建，避免变量、类静态属性带来的内存泄漏。对长期运行的服务来说，这是性价比非常高的保护措施。
2.3 OPcache 和 JIT：让 CPU 省下来干正事
如果你还没开 OPcache，那基本等于让 CPU 每来一个请求就重新“读一遍书”。PHP 的编译过程非常耗时，代码文件越大，编译开销越高。OPcache 能把编译好的字节码缓存到共享内存里，第二次请求直接执行字节码，不再重新 parse。
生产环境我一般这样配：
zend_extension=opcache.so opcache.enable=1 opcache.memory_consumption=128 opcache.max_accelerated_files=100000 opcache.validate_timestamps=1 opcache.revalidate_freq=60 opcache.jit=tracing opcache.jit_buffer_size=64MPHP 8 之后 JIT 可以把热点代码编译成机器码，对 CPU 密集型的循环、数学计算有明显提升。但要注意，如果你的业务全是数据库查询和接口调用，JIT 带来的收益非常有限，别指望它救命。
3. 单进程写不好并发，就用多进程/多线程方案
3.1 用 Swoole 常驻内存跑服务
PHP-FPM 是“请求来了，拉起进程，处理完，销毁资源”的模型，很多对性能有要求的团队会选择让 PHP 常驻内存，典型方案就是 Swoole。Swoole 扩展提供 HTTP 服务、WebSocket、协程、进程管理，能把 PHP 从“每次请求重新编译执行”变成“常驻内存的事件驱动服务”。
一个简化的 Swoole 服务大概长这样：
<?php use Swoole\Http\Server; use Swoole\Coroutine; $server = new Swoole\Http\Server('0.0.0.0', 9501, SWOOLE_PROCESS); $server->set([ 'worker_num' => 16, // 一般跟 CPU 核数对齐 'enable_coroutine' => true, ]); $server->on('Request', function ($request, $response) { // 这里可以用协程并发请求多个服务 Coroutine::create(function () use ($response) { $msg = file_get_contents('http://api.example.com/hello'); $response->end($msg); }); }); $server->start();其中的核心思想是：单个 worker 进程里的协程可以在等待 I/O 时主动让出 CPU，去执行其他协程，所以 16 个 worker 就能撑住非常高的并发连接数，而不是像传统 FPM 那样每个请求独占一个进程。
3.2 用 RoadRunner 把 PHP 变成 Worker
如果不想在 PHP 扩展层面做事，还有一种方案是把 PHP 变成 Worker，由外部调度器来管理进程生命周期，典型代表是 RoadRunner。这个工具用 Go 写调度层，PHP 只负责干活，进程常驻内存，通过标准输入输出和调度器通信。
| 方案 | 运行模型 | 适合场景 | 维护成本 |
|---|---|---|---|
| PHP-FPM | 多进程，请求结束释放资源 | 传统 Web 业务 | 低 |
| Swoole | 常驻内存，协程，多 Worker | 高并发 API、WebSocket | 中 |
| RoadRunner | Go 调度 + PHP Worker | 微服务、队列消费 | 中 |
只要你的业务确实压到了 PHP-FPM 的瓶颈，引入常驻内存方案是很有价值的。但如果只是普通 CRUD 接口，强行上 Swoole 或 RoadRunner，反而会引入内存管理、热更新、进程守护等一系列复杂度，得不偿失。
3.3 只装扩展不方便，就用 pcntl_fork 做进程池
很多人写后台脚本的时候不想依赖 Swoole，那 PHP 自带的pcntl_fork也能做多进程。下面这个例子会 fork 出 16 个子进程来处理任务：
<?php $workerCount = 16; for ($i = 0; $i < $workerCount; $i++) { $pid = pcntl_fork(); if ($pid === -1) { exit('fork failed'); } if ($pid === 0) { // 子进程逻辑 while (true) { $task = getTaskFromQueue(); handleTask($task); usleep(100000); } exit(0); } } while (pcntl_waitpid(0, $status) > 0) { // 主进程等待子进程退出，回收僵尸进程 }这里有一个容易踩坑的点：父进程如果事先建立了 MySQL 或 Redis 连接，fork 之后子进程会复制这份连接资源，多个子进程同时复用同一连接会造成数据错乱。正确做法是父进程只负责 fork，真正的数据库连接、Redis 连接要在每个子进程内部单独建立。
4. 把耗时任务拆出去：消息队列是16核的好朋友
4.1 哪些任务必须异步化
如果你的业务流程里有“发邮件、发短信、生成报表、导出 Excel、处理图片、调用第三方接口”这些操作，尽量别在用户请求里同步执行。一次请求如果花 2 秒生成报表，用户就在页面干等 2 秒，同时这个 php-fpm worker 一直被占着，CPU 和进程池都会被拖垮。
正确做法是：请求进来后，把任务描述丢到消息队列里，立刻给用户返回“任务已受理”。后台再启动一堆消费进程，从队列里慢慢取任务执行。这样用户请求是毫秒级返回，任务的 CPU 消耗也分摊到了后台进程上，16 核才能被真正利用起来。
4.2 队列消费者的横向扩容
队列消费者本质上就是一个常驻进程，循环从队列里取任务。如果你用 Supervisor 管理消费者，可以让它直接拉起 16 个进程：
[program:queue-worker] command=php /app/worker.php process_name=%(program_name)s_%(process_num)02d numprocs=16 autostart=true autorestart=true stderr_logfile=/var/log/worker.err.log16 核机器上开 16 个消费者，如果是 CPU 密集型任务，这 16 个进程就能把 16 个核心全部占满。如果是 I/O 密集型任务，比如任务里要请求外部接口，消费者可以开到更多，比如 32 甚至 64，因为大部分时间都在等待网络响应。
需要注意的是，消费者进程数也不是无脑加。每个消费者都会申请自己的数据库连接、Redis 连接，连接数会跟着涨。如果消费者的任务非常轻量，开太多进程反而会让 CPU 在进程切换上消耗过多。
4.3 处理完还要注意进程内存泄漏和任务幂等
常驻进程最大的敌人是内存泄漏。一个消费进程跑几天，内存占用越来越离谱。最常见的解法是让进程处理一定数量的任务后主动退出，由 Supervisor 重新拉起。简单一点，可以在代码里判断：
if ($handledCount >= 1000) { exit(0); } if (memory_get_usage(true) > 256 * 1024 * 1024) { exit(0); }另外，消息队列重试机制会带来幂等问题。同一个任务可能被执行两次，如果你的任务是扣款、发短信、加积分，必须在业务上做好幂等保护，比如在数据库里记录唯一处理标识。
5. 数据库、Redis、外部接口才是真正的“拖后腿”大王
5.1 连接池、慢查询和 N+1 查询
很多 PHP 项目 CPU 根本没吃满，全卡在数据库上了。一个最简单的 N+1 场景：查出 100 个用户，然后循环去查每个用户的订单，这样会产生 1 条查询用户 + 100 条查询订单的 SQL，一共 101 次网络往返。哪怕每次都只要 1ms，这就是 101ms 的等待时间。
解决办法很简单，要么 JOIN 一次查出来，要么先用WHERE user_id IN (...)批量查出订单再分组。一次请求的 SQL 往返越少，CPU 空等的时间就越少。
| 场景 | 慢的原因 | 常规解法 |
|---|---|---|
| 100 个用户循环查订单 | N+1 查询，网络往返多 | JOIN / IN 批量查询 |
| 大量小写入 | 每条 SQL 都等磁盘刷盘 | 批量 INSERT |
| Redis 多次读写 | 网络往返多 | Pipeline 合并 |
| 外部接口超时 | 对端响应慢 | 并发调用 / 设置超时 |
5.2 减少等待：批量读写、Pipeline、持久连接
Redis 每次请求都有网络往返，如果你在循环里执行 SET、GET，可以做 Pipeline 合并。PHP 里的 phpredis 扩展一般支持：
$redis->multi(\Redis::PIPELINE); for ($i = 0; $i < 1000; $i++) { $redis->set("key:$i", $data[$i]); } $redis->exec();这样 1000 次写入在网络层面几乎等价于一次大请求，CPU 空等时间大幅减少。
数据库连接是否用持久连接，这里有个取舍：持久连接能减少每次请求建立 TCP 连接的开销，但如果配置了太多 php-fpm worker，持久连接会在数据库上堆积大量空闲连接，拖垮数据库的连接数上限。所以我不建议一上来就开 pconnect，先把慢查询和连接池问题处理好再说。
5.3 把“等外部”变成“并发发请求”
如果你的业务里要同时调用三个外部接口：A 要 300ms，B 要 300ms，C 要 300ms。串行调用总共 900ms，并发调用只需要 300ms 左右。这可能是优化空间最大、也最容易被忽略的一步。
PHP 原生的curl_multi就可以做并发 HTTP 请求：
$mh = curl_multi_init(); $handles = []; foreach ($urls as $i => $url) { $handles[$i] = curl_init($url); curl_multi_add_handle($mh, $handles[$i]); } do { curl_multi_exec($mh, $running); curl_multi_select($mh); } while ($running > 0); foreach ($handles as $handle) { $content = curl_multi_getcontent($handle); curl_multi_remove_handle($mh, $handle); curl_close($handle); } curl_multi_close($mh);如果你用了 Swoole，协程 HTTP 客户端更优雅，写法也更像同步代码，但底层已经是异步并发。这类优化不需要额外买服务器，就能让同样一段代码的吞吐量翻好几倍，我觉得这才是“把 16 核利用到极致”比较正确的方向。
6. 排查与压测：别凭感觉，直接用数据说话
6.1 压测命令：ab / wrk / hey
优化完以后，别用“页面感觉快了”来判断效果。我一般直接上压测工具，先压一遍，改配置，再压一遍，对比数据。
# ab 压测，10万请求，200并发 ab -n 100000 -c 200 -k http://127.0.0.1/test.php # wrk 压测，8线程，400并发，持续30秒 wrk -t8 -c400 -d30s http://127.0.0.1/ # hey 压测，10万请求，200并发 hey -n 100000 -c 200 http://127.0.0.1/重点关注三个数据：QPS、平均延迟、P99 延迟。如果 QPS 高但 P99 很高，说明存在长尾请求，需要排查慢 SQL 或第三方接口；如果 QPS 上不去但 CPU 没满，多半是锁、连接数、网络参数的问题。
6.2 用火焰图和 Xdebug 找出 CPU 热点
压测发现 CPU 很高但吞吐不行的时候，就要知道 CPU 到底花在哪个函数上了。本机开发环境可以开 Xdebug profiler：
xdebug.mode=profile xdebug.output_dir=/tmp跑完请求之后会生成 cachegrind 文件，用图形工具能看到每个函数的耗时占比，这是定位 CPU 热点最直接的手段。
线上环境不建议开 Xdebug，但可以用perf top、strace -c -p PID看系统层面。很多 PHP 卡顿其实是卡在系统调用上了，比如持续的 read/write 等待，这时候代码逻辑本身没有问题，问题在网络或磁盘。
6.3 常见问题速查表
| 现象 | 可能原因 | 优先排查 |
|---|---|---|
| 16核只有1核忙 | 单进程 / 全局锁 / 串行业务 | php-fpm 进程数、锁、单例连接 |
| CPU 总体低但请求慢 | I/O 等待 | 慢查询、Redis、外部接口 |
| CPU 100% 但吞吐上不去 | 进程过多调度开销 / 死循环 | pidstat、火焰图、pm.max_children |
| QPS 上不去但 CPU 没满 | 并发连接 / 系统限制 | ulimit、somaxconn、worker_connections |
这张表我每次做性能排查都会翻一遍。很多问题只要定位方向正确，解决起来并不难，怕的就是毫无依据地这里改一下、那里调一下。
7. 最后再分享两个“土办法”和扩展方向
7.1 把系统参数和 Nginx 也顺手调一调
后端 PHP 的进程数调完了，前端 Nginx 也可能成为瓶颈。我一般会把 Nginx 的worker_processes改成auto，让工作进程跟随 CPU 核数变化。然后适当调大worker_connections，加大 keepalive 连接数，避免频繁建立 TCP 连接。
系统层面，ulimit -n要调大，不然并发一上来就会出现 “too many open files”。net.core.somaxconn也要注意，否则高并发时内核 accept 队列满了，请求会直接被丢弃。这些参数都不复杂，但往往是压测数据上不去的最后一根稻草。
7.2 别把“吃满 CPU”当成唯一目标
我踩过几次坑之后，最大的体会是：16 核本身不是问题，问题是很多人一开始就把“CPU 利用到极致”等同于“所有核心都要忙起来”。其实对 PHP 这种偏 I/O 的 Web 服务来说，CPU 偶尔有空闲反而说明没有资源浪费。一台 16 核机器跑满 4 核，但 QPS 已经完全满足业务，那它就是在以最省成本的方式运行。
真正应该追求的目标，是当流量来临时，请求不会被单个瓶颈挡住，而是可以平滑地、并行地打满所有核心。先用 mpstat 和压测把现状量化，再调整进程数、OPcache、异步化和数据库查询。最后你会明白，所谓极致利用，不是让所有核无脑飙红，而是让每个请求都尽可能少等待、多干活。
