workerman的count不能直接套用cpu核数，需按业务类型设定：io密集型设为cpu核数×3–5，cpu密集型设为cpu核数或+1；内存是硬瓶颈，须据实测rss值估算安全上限，并通过压测监控调优。
Workerman 的 count 值不能直接套用 CPU 核心数
Workerman 是 PHP 进程模型，每个 Worker 进程是独立的 OS 进程，调度由内核完成；它**不支持**类似 Nginx 的 worker_cpu_affinity 指令——没有内置 CPU 亲和性绑定机制。强行用 taskset 手动绑核，收益极低，还可能干扰系统调度弹性。
真正影响并发上限的是 count 设置是否匹配业务类型：
- IO 密集型（如频繁调用 MySQL、Redis、HTTP API）：用阻塞式客户端时，进程大部分时间在等响应，
count可设为 CPU 核数 × 3～5（例如 8 核 → 24～40） - CPU 密集型（如大量 JSON 编解码、加密计算、无外部依赖逻辑）：
count接近 CPU 核数或 +1 更稳，再多只会加剧争抢 - 不确定类型？从
count = nproc × 2起步，压测时盯top里各 PHP 进程的%CPU和RSS内存值，再调
内存比 CPU 更早成为 count 上限瓶颈
每个 Workerman 进程常驻内存约 30–60MB（加载框架、配置、OPcache 后会更高），不是“轻量线程”。设高了容易触发 OOM 或频繁 swap。
估算安全上限要算真实内存：
- 用
ps aux --sort=-%mem | grep php查几个运行中 Worker 的RSS值，取平均 - 公式：
最大安全 count ≈ (总内存 GB × 1024) × 0.8 ÷ 单进程 RSS(MB)（留 20% 余量） - 例如：16GB 内存，实测单进程 RSS=48MB →
(16 × 1024) × 0.8 ÷ 48 ≈ 273，但线上建议先设 ≤200，观察负载
开启 reusePort 能缓解“惊群”，但不等于能无脑加 count
设 $worker->reusePort = true; 后，内核会在新连接到达时哈希分发到不同 Worker，避免所有进程被唤醒却只有一个能 accept——这确实提升连接接入效率，尤其在短连接洪峰时明显。
但它解决的是“唤醒开销”，不是“处理能力”。如果后端 Redis 响应慢、或业务逻辑有同步阻塞，加再多 Worker 也只是堆等待队列，CPU 利用率反而可能掉下去。
验证是否真需要更多 count，得看两个指标：
-
netstat -ant | grep :端口 | wc -l—— 当前 ESTABLISHED 连接数是否持续逼近worker_connections上限 -
cat /proc/$(pgrep -f "Worker::runAll" | head -1)/status | grep -i vmrss—— 单进程 RSS 是否稳定，没持续上涨（排除内存泄漏）
别碰 taskset 绑核，除非你明确知道 NUMA 或中断亲和问题
有人看到 Nginx 推荐 worker_cpu_affinity，就给 Workerman 进程也套 taskset -c 0-3 php start.php。这基本无效：
- Workerman 没有固定事件循环绑定某类请求的机制，不像 Nginx worker 长期持有 SSL cache、共享内存 slab 等热数据
- PHP 进程生命周期短（尤其 HTTP 场景），L1/L2 缓存局部性收益微乎其微
- 若服务器是 NUMA 架构且网卡中断集中在某节点，应优先调
irqbalance或绑定网卡中断，而不是绑 PHP 进程
真正该花时间的地方，是检查 onMessage 里有没有隐式阻塞调用、OPcache 是否启用、日志是否同步刷盘——这些对性能的影响，远大于手动绑核。
