webman/workerman的$worker->count必须按业务类型（io/cpu/混合）、实测rss内存、服务器资源三者联动设定：io密集型建议cpu核数×3–5，cpu密集型设为核数或+1，混合型先设×2再压测调优；硬上限公式为（总内存gb×1024÷单进程rss mb）×0.8并向下取整。

Workerman多进程count设置直接影响服务并发能力与稳定性，设低了连接排队、CPU空转，设高了内存溢出、上下文切换频繁——必须按业务类型、实测内存、服务器资源三者联动调整，不能套用固定倍数。

先判断你的业务属于哪一类

阻塞调用多（如mysqli_query、file_get_contents、curl_exec未设超时）→ IO密集型；纯计算、图像压缩、加密解密等不等外部响应→ CPU密集型；混合场景（比如查库+计算+调API）→ 优先按IO密集型起步，再根据监控调。

关键看代码里有没有【同步阻塞IO调用】：只要存在一个未封装为异步的MySQL查询或HTTP请求，整个Worker就卡住，此时必须按IO密集型配置count。

按类型设定初始count值

方法一：IO密集型（含数据库/Redis/HTTP调用）

第一步：获取CPU逻辑核心数，执行nproc命令，假设返回4；

第二步：从cpu_count × 3起步，即设为12；

第三步：启动服务后，立即执行ps aux --sort=-%mem | grep php | head -n 5，抓取5个Worker进程的RSS列，取平均值（单位KB），转换为MB；

这一步漏掉就容易OOM——别信“空进程只占20MB”，加载了Eloquent、Redis扩展、日志中间件后，实测常达45–68MB。

方法二：CPU密集型（无外部IO，纯PHP运算）

Codex Bridge

一款AI工具，主要用于将编码任务调度到本地 OpenAI Codex CLI，支持后台执行、状态轮询以及可交互式回答的澄清问题。适用于 OpenClaw 需要……，适合需要提升相关任务效率的用户。

下载

直接设为CPU核心数或+1，4核机器设4或5即可；再多只会加剧调度开销，QPS反而下降。

方法三：混合型（推荐先用此法探路）

设为cpu_count × 2，例如4核设8；运行10分钟后，用top观察各php进程%CPU是否持续高于70%，且vmstat 1 5中cs（context switch）值稳定在500以下；满足则保留，否则按IO密集型上调。

算出内存硬上限再截断

公式：【最大安全count ≈ (总内存GB × 1024) ÷ 单Worker平均RSS(MB) × 0.8】，结果向下取整。

例如：16GB内存服务器，实测单Worker RSS为52MB → 16 × 1024 ÷ 52 × 0.8 ≈ 252 → 最大设252，但实际建议留余量，设220以内。

注意：这个数是理论顶格，不是推荐值。压测时若QPS不再上升、或netstat -s | grep "packet receive errors"开始增长，说明已触达内核瓶颈，必须同步调net.core.somaxconn等参数，不能只加count。

启用reusePort是否能多开几个？

可以微调提升，但有前提：Linux内核≥3.9、PHP≥7.0、且stream_socket_server()底层支持SO_REUSEPORT（低版本PHP会静默忽略）。

开启后，原设24可试28，但【若RSS已逼近内存上限，开reusePort毫无意义】，还会因内核哈希表膨胀略微增加延迟。

验证是否生效：启动后执行ss -ltnp | grep :端口，若同一端口出现多个PID，说明启用成功。