应线上实测rss值：启动后运行ps aux --sort=-%mem | grep php，取稳定worker进程rss中位数（kb），再除以进程数；若启用大opcache，单进程rss通常高15–25mb。
Workerman单进程内存不是“空着也占满”，但设高了真会OOM；百万连接不等于百万份内存，关键看活跃连接数和缓冲区使用方式。
怎么估算单个Worker进程真实内存（RSS）？
别信“每个进程固定30MB”这种笼统说法——实际值取决于你加载了什么、开了什么调试、有没有用Redis/MySQL长连接池、是否启用opcache且memory_consumption设得很大。最可靠的方式是线上实测：
- 启动Workerman后等业务流量上来，运行
ps aux --sort=-%mem | grep php - 挑几个稳定运行5分钟以上的Worker进程，记下它们的
RSS列数值（单位KB） - 取中位数，再除以进程数，就是你当前配置下单进程真实内存占用
- 如果用了
opcache.enable=1且opcache.memory_consumption≥ 256M，单进程RSS通常比默认高15–25MB
百万并发连接到底吃多少内存？
百万连接 ≠ 百万活跃连接。ESTABLISHED但空闲的TCP连接只占几百字节socket结构体，真正吃内存的是：
- 每个活跃连接的读写缓冲区（按需分配，非静态预留）
- 每个连接绑定的PHP对象（比如
$connection->session存了大数组） - 全局共享资源（如Redis连接池、定时器队列、WebSocket广播缓存）
举例：16GB内存服务器，实测单Worker RSS为48MB，按公式 16 × 1024 ÷ 48 ≈ 341，理论最多跑341个Worker；但留20%余量后应设$worker->count ≤ 270。此时若总连接数达100万，平均每个Worker承载约3700连接——只要其中活跃连接占比＜10%，缓冲区压力就可控。
哪些配置会悄悄拉高内存？
这些地方改错一个，单进程内存可能多涨20MB以上：
-
client_body_buffer_size和client_max_body_size设得过大（尤其上传接口），导致每个连接预分配大量缓冲 - 在
onMessage里用static $cache = []缓存用户数据，没做生命周期管理，越积越多 - 数据库连接池
max_connections设成100，但实际并发请求只有20，空闲连接长期占着PDO对象和内存 - 开了
debug模式且日志写到文件，每次var_dump或print_r都往内存塞大字符串
reusePort能降低内存吗？
不能。开启$worker->reusePort = true只是让内核把新连接哈希分发到不同Worker，解决“惊群”问题、提升CPU利用率，但它不减少单个Worker的内存开销，也不改变连接缓冲区分配逻辑。设了reusePort之后仍要按单Worker内存上限来规划count，否则照样Cannot allocate memory。
最容易被忽略的一点：内存瓶颈往往不出现在连接建立阶段，而出现在业务逻辑里——比如一次广播操作把10万在线用户ID全读进内存再遍历发送。这时候调低count没用，得重构广播逻辑为分批+协程式推送。
