完全正常。RSS统计进程全部物理内存占用（含OPcache、Go运行时、共享库等），memory_get_usage(true)仅统计Zend堆内存，二者维度不同；典型差值达70MB以上属合理现象。
FrankenPHP 进程 RSS 和 PHP 内存统计（memory_get_usage）数值差异大，正常吗？
完全正常。RSS 和 memory_get_usage() 统计的是两类根本不同的内存，不是测量误差，而是观测视角不同——一个看操作系统分配的物理页，一个看 PHP Zend 引擎管理的堆内存块。
为什么 RSS 总是远大于 memory_get_usage(true)？
RSS（Resident Set Size）是 Linux 内核统计的该进程当前实际驻留在物理内存中的总页数，包含：
• PHP 解释器自身代码段、全局符号表、扩展（如 opcache、pdo_mysql）加载的共享库
• OPcache 缓存的 opcode（独立于 PHP 堆，不计入 memory_get_usage）
• 扩展预分配的内存池（例如 mysqlnd 的 mysqlnd.net_read_buffer_size）
• FrankenPHP Go 主进程占用的内存（goroutine 栈、Caddy HTTP 连接缓冲区等）
而 memory_get_usage(true) 只返回 Zend 内存管理器（emalloc）当前已分配且未释放的内存块总和，不含任何 C 层预分配或共享库开销。
典型表现：
• memory_get_usage(true) 显示 12MB → PHP 脚本运行时堆占用
• ps -o rss= -p $(pgrep -f frankenphp) 显示 86MB → 实际物理内存占用
两者差值（约 74MB）基本就是 OPcache（设为 128MB 时实际常驻约 60–70MB）、Go 运行时、Caddy TLS 缓冲区等的贡献。
哪些配置会让 RSS 和 PHP 内存差得更离谱？
以下设置会显著拉大 RSS 与 memory_get_usage() 的差距，但属于合理行为：
• opcache.memory_consumption 设为 128 或 256（单位 MB）：这部分内存由 OPcache 直接 mmap 分配，完全绕过 Zend 堆管理
• 启用 apcu.shm_size=64M：APCu 共享内存段计入 RSS，但不计入 PHP 脚本内存统计
• mysqlnd.net_read_buffer_size = 262144（256KB）：每个活跃 MySQL 连接都会额外吃掉这块固定缓冲区，且多个连接共享时 RSS 累加
• FrankenPHP 启动参数含 --workers=8：每个 worker 线程都持有一份 OPcache 和 APCu 映射，RSS 是线程间叠加的，而 memory_get_usage() 每次只读当前请求线程的 Zend 堆
立即学习“PHP免费学习笔记（深入）”；
查 RSS 时别被 ps 的默认单位误导
ps aux 默认显示的 %MEM 和 VSZ 是虚拟内存（VSS），不能反映真实压力；RSS 列单位是 KB，但容易看错小数点。
推荐用精确命令：
• cat /proc/$(pgrep -f frankenphp)/statm | awk '{print $2 * 4}' → 输出 RSS 字节数（$2 是页数，×4 得 KB）
• ps -o pid,rss,vsz -C frankenphp → 清晰分离 RSS/VSS
• 若容器部署，直接看 docker stats 的 MEM USAGE / LIMIT，它底层读的就是 cgroup 的 memory.current，比 RSS 更贴近 OOM 风险点
真正要盯的是 RSS 是否持续增长且不回落（可能 Go 层泄漏），以及 memory_get_peak_usage(true) 是否逼近 memory_limit（说明 PHP 脚本有泄漏）。两者差得多本身不是问题，差得越来越大会是问题。
