Webman CPU 持续90%+，首要排查Worker::$onWorkerStart中是否存在死循环、同步阻塞调用（如sleep、轮询数据库）、超大配置加载或未适配的同步SDK，应将耗时操作移至onMessage或异步队列。
Webman 启动后 CPU 持续 90%+，先看 Worker::$onWorkerStart 里有没有死循环或密集计算
Webman 是常驻进程，onWorkerStart 回调只执行一次，但一旦写错就可能让整个 Worker 进程卡死在 CPU 上。常见错误包括：
– 在回调里调用 sleep() 或 usleep() 而没配合事件循环（Workerman 不吃这套）
– 错误地用 while(true) 手动轮询数据库或 Redis（应该用异步客户端 + 回调）
– 初始化阶段加载超大配置文件并做嵌套遍历解析（比如 YAML 解析 + 递归 merge）
– 使用了未适配 Workerman 的同步 SDK（如某些旧版阿里云 OSS SDK），导致阻塞主线程
建议把所有耗时操作移出 onWorkerStart，改到 onMessage 或异步任务队列中处理。
$worker->count 设多少才合理？别盲目堆核数
Workerman 默认 count = 1，单进程无法压满多核。但设成 cpu_count * 4 反而会因进程调度和锁竞争拖慢性能。
– 真实推荐值：CPU 物理核心数的 1.2 ~ 1.8 倍（例如 8 核服务器设 10 或 12）
– 如果业务含大量 I/O（如频繁调外部 HTTP、Redis），可适当上浮至 2.0 倍
– 若启用了 $worker->reusePort = true，count 值可以更接近物理核数，避免端口争抢
– 注意：PHP 进程本身不是轻量级，每个 Worker 都会加载全部 Composer 类，内存占用随 count 线性增长，需同步监控 memory_get_usage()
为什么开了 reusePort 还是出现连接排队？检查系统 net.core.somaxconn
$worker->reusePort = true 只是让多个 Worker 进程能同时 bind() 同一端口，但真正决定“能挂起多少待完成三次握手连接”的是 Linux 内核参数 net.core.somaxconn。
– 默认值通常只有 128，高并发下新连接会被内核直接丢弃（现象是客户端偶发 Connection refused 或超时）
– 应该调高：运行 sudo sysctl -w net.core.somaxconn=65535，并写入 /etc/sysctl.conf 永久生效
– 同时检查 Webman/Workerman 的 listen 配置是否显式设置了 backlog（如 tcp://0.0.0.0:8080?backlog=65535），否则仍走内核默认值
– 补充：如果用 Nginx 做反向代理，还要确认 proxy_pass 指向的 upstream 中 max_conns 和 queue 设置是否足够
数据库慢查不报错，但 Webman 响应变长——必须用异步客户端
Webman 虽然基于事件驱动，但默认 MySQLi/PDO 是同步阻塞的。一个慢查询会让整个 Worker 进程卡住，无法响应其他请求。
– 必须切换为异步数据库客户端，如 workerman/mysql 或 swoole/mysql（注意 Webman 兼容 Swoole 协程需额外适配）
– 不要试图用 pcntl_fork 或 proc_open 模拟异步——这会破坏事件循环，且开销更大
– Redis 同理：禁用 phpredis 同步扩展，改用 workerman/redis 或 co/redis（若启用协程）
– 验证是否生效：在 onMessage 中故意 sleep(3)，观察其他并发请求是否被阻塞；若阻塞，说明仍有同步调用残留
立即学习“PHP免费学习笔记（深入）”；
Webman 的性能瓶颈往往不在框架层，而在你写的那几行初始化代码或一个没意识到的同步调用。常驻进程模型放大了任何微小设计偏差的影响，越早用 strace -p 或 perf top 定位热点，越不容易在线上被突发流量打穿。
