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运算）
直接设为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，说明启用成功。
