PHP本身不感知CPU路数，资源分配由运行环境、进程模型及操作系统调度决定；需合理配置php-fpm进程数、启用NUMA绑定、均衡CPU负载才能充分利用双路CPU算力。
PHP本身不感知CPU路数，但进程模型影响资源分配
PHP是解释型语言，运行时依赖Web服务器（如Apache、Nginx）或Swoole等运行环境，它自身没有“绑定双路CPU”或“多路调度”的概念。真正决定CPU资源使用方式的是：PHP进程/线程的启动方式、Web服务器的MPM模型、以及操作系统层面的调度策略。
常见误区是认为“装了双路CPU，PHP就自动跑满32核”。实际上，单个php-fpm worker进程默认只用1个逻辑CPU核心；即使服务器有两颗CPU（共32线程），若pm.max_children = 10，最多也只并发占用10个核心——其余资源闲置。
-
php-fpm的pm = static或pm = dynamic直接决定常驻进程数，这是控制CPU利用率的第一杠杆 - Linux默认启用NUMA，双路服务器上跨CPU访问内存有延迟；若
php-fpm进程被调度到远离其分配内存的CPU节点，性能反而下降 - Nginx +
php-fpm架构中，Nginx worker进程数建议设为cpu_count / 2（非cpu_count），避免争抢
如何让PHP实际用上双路CPU的全部算力
关键不是“支持”，而是“配得对”。双路服务器的优势体现在高并发、高吞吐场景，需从进程数、IO模型、内存亲和性三方面协同调整。
- 查清真实逻辑CPU数：
nproc或lscpu | grep "CPU(s):"，注意区分物理CPU数（Socket(s)）与逻辑核心数（CPU(s)） -
php-fpm.conf中设置合理pm.max_children：一般按总内存 × 0.8 / 单个PHP进程平均内存计算，而非盲目设为nproc值 - 启用
pm.process_idle_timeout和pm.max_requests防止长连接+内存泄漏拖垮整组worker - 如用Swoole，必须显式调用
swoole_set_process_name()并配合task_worker_num分离CPU密集型任务，否则EventLoop线程会卡死在单核
双路服务器上最容易被忽略的NUMA陷阱
双路Xeon平台默认开启NUMA，php-fpm进程可能被调度到CPU1，却从CPU0的内存节点分配堆内存，导致30%+延迟增长。这不是PHP Bug，是Linux调度行为。
- 用
numactl --hardware查看NUMA节点分布；用numastat -p $(pgrep php-fpm)观察进程内存跨节点访问比例 - 强制绑定：启动
php-fpm前加numactl --cpunodebind=0 --membind=0 /usr/sbin/php-fpm（节点0仅作示例，需按实际拓扑选） - 更稳妥做法：在
/etc/default/php-fpm里写入PHPFPM_OPTS="--cpunodebind=0 --membind=0"，确保所有worker统一策略 - 若用Docker，需加
--cpuset-cpus和--memory-swappiness=0，否则cgroup会干扰NUMA局部性
验证是否真正在用双路资源：别只看top
top 显示CPU总体使用率高，不代表双路均衡——可能所有PHP进程全挤在CPU0的8个核心上，CPU1完全空闲。必须分层验证。
- 看核级负载：
mpstat -P ALL 1，观察每个逻辑CPU的%usr是否均匀（差异超2倍即不均） - 看进程分布：
ps -eo pid,psr,comm | grep php-fpm，psr列显示实际运行在哪个CPU编号上 - 压测时监控
/proc/interrupts，如果eth0-TxRx中断长期集中在某几个CPU，说明网卡RSS未启用或配置不当，会间接导致PHP请求堆积在固定worker上 - PHP内部无法直接获取当前运行CPU，但可通过
getrusage(RUSAGE_SELF)中的ru_stime/ru_utime辅助判断单次请求是否遭遇调度延迟
双路部署的复杂点不在PHP源码，而在Linux内核调度、NUMA内存策略、以及Web服务与PHP运行时的耦合深度。一个没调好的pm.max_spare_servers，可能比CPU路数本身更能决定你的QPS上限。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
