workerman应通过php start.php status命令查看mem_usage列（单位mb）监控真实rss内存，该值比memory_get_usage()更准确，因后者遗漏扩展缓冲、opcache共享内存及循环引用对象；线上需用ps aux取rss中位数校准扩缩容阈值。
直接看 status 命令的 mem_usage 列
执行 php start.php status 后，输出表格里每行对应一个 Worker 子进程，mem_usage 这一列就是该进程当前 RSS 内存占用（单位 MB）。这个值是真实、可比、线上可用的核心指标——它不包含共享库虚占，也不受 opcache 预分配干扰，只反映进程实际驻留内存。
注意：mem_usage 是动态值，会随连接活跃度、缓存增长、对象堆积实时变化。如果某进程该值持续高于其他进程 20MB+，大概率存在泄漏点或资源独占逻辑。
为什么不能只信 memory_get_usage()
memory_get_usage() 返回的是 PHP 堆内已分配但未释放的字节数，它漏掉三类关键内存：
- PHP 扩展（如 Redis、MySQLi）内部 malloc 的缓冲区
- opcache 编译后脚本的共享内存段（即使
opcache.enable=1，这部分不计入 PHP 堆） - 循环引用导致的“逻辑死亡对象”——引用计数未归零，GC 没触发，
memory_get_usage()完全不体现
所以你看到 memory_get_usage() 稳定在 8MB，但 ps aux 显示 RSS 已到 65MB，这非常正常。真正要盯的是后者。
线上实测 RSS 中位数才是基准线
status 命令的 mem_usage 虽然方便，但它基于 /proc/pid/status 计算，偶尔有瞬时抖动。生产环境压测或调优时，必须用系统级命令交叉验证：
- 运行
ps aux --sort=-%mem | grep php - 挑出稳定运行 5 分钟以上、状态为
ok的 Worker 进程（排除刚启动或正在 stopping 的） - 记下它们的
RSS列（单位 KB），取中位数 - 再除以
$worker->count，得出单进程平均真实内存
这个值决定你能不能扩 count：比如中位数 RSS 是 48MB，服务器 16GB，按 20% 余量算，最多只能设 $worker->count = 270。设高了，OOM 就在下一次流量高峰。
哪些配置会让 RSS 暴涨却不易察觉
这些地方改错一个，单进程 RSS 可能多涨 15–30MB：
-
opcache.memory_consumption设 ≥ 256M，且启用了opcache.enable=1→ 单进程 RSS +15–25MB（预加载所有脚本的代价） -
client_max_body_size设成 100M（尤其上传接口），每个新连接都会预分配缓冲 → 空闲连接也吃内存 - 在
onMessage里用static $cache = []存用户 session，又没在onClose清理 → 对象越积越多，RSS 持续爬升 - Redis 连接池
max_connections设 100，但实际并发仅 20 → 80 个空闲 PDO 对象长期驻留
最麻烦的是：这些上涨往往不伴随错误日志，total_request 仍在增长，connections 看似正常——直到某天 Cannot allocate memory 直接 kill 进程。
