FrankenPHP进程里OPcache共享内存、Go运行时堆、Caddy网络栈、线程栈及mmap映射文件等内存不由PHP代码分配，memory_get_usage()无法统计，需通过/proc/PID/status和pmap定位。
FrankenPHP 进程里哪些内存不是 PHP 代码分配的
FrankenPHP 是 Go 主进程 + 内嵌 PHP 运行时的混合体，memory_get_usage() 只能拿到 PHP 堆内内存，而 Go 部分、Caddy 网络栈、OPcache 共享内存、线程栈、mmap 映射的文件（如 OPcache 的共享内存段）全都不在它的统计范围内。你看到 PHP 脚本只用了 20MB，但 ps 显示 RES 占了 180MB，那多出来的 160MB 就是这些“PHP 之外”的部分。
用 /proc/PID/status 和 pmap 定位非 PHP 内存来源
最直接的办法是查 FrankenPHP 主进程的内存分布：
-
cat /proc/$(pgrep -f "frankenphp")/status | grep -E "VmRSS|VmSize|VmData|VmStk|VmExe"——VmRSS是真实物理内存占用，VmData包含 Go 的堆和全局变量，VmStk是线程栈总和（FrankenPHP 默认启多个 OS 线程），VmExe是二进制本身大小 -
pmap -x $(pgrep -f "frankenphp") | tail -n 20—— 查看 top 20 大的内存映射段，重点关注：[anon]（Go 堆/PHP worker 共享区）、libphp.so（PHP 引擎本身）、frankenphp（Go 代码段）、以及类似/dev/zero (deleted)这种匿名 mmap（通常是 OPcache 共享内存） - 若启用 OPcache，
ipcs -m会列出共享内存段，大小通常为opcache.memory_consumption值；它不计入memory_get_usage()，但算进进程 RSS
区分 Go runtime 和 PHP worker 的内存增长趋势
单纯看总量没用，得看谁在涨：
- 连续采样
VmRSS：如果每分钟稳定 +2MB，且frankenphp_busy_threads指标无明显上升，大概率是 Go 侧泄漏（比如日志缓冲未 flush、HTTP client 连接池未复用） - 如果
VmRSS飙升但memory_get_peak_usage(true)没变，说明增长来自 Go 或 mmap，不是 PHP 脚本问题 - 重启 FrankenPHP 后
VmRSS初始值比上次高（比如从 120MB → 150MB），说明 Go runtime 初始化阶段就占更多——检查是否加载了额外 Caddy 插件或自定义 Go 扩展
为什么不能只信 top 或 htop 里的 %MEM
top 的 %MEM 是按系统总内存比例算的，对单容器部署毫无意义；更糟的是它默认显示 VIRT（虚拟内存），而 FrankenPHP 因大量 mmap 会虚高到几个 GB，完全误导判断。必须盯死 RES（即 VmRSS），并确认它是否逼近容器 mem_limit 或 systemd 的 MemoryMax。一旦 RES 持续 > 90% 上限，OOM Killer 就随时可能介入——这时再查 PHP 脚本内存已晚，得先砍 Go 侧开销或调低 OPcache。
立即学习“PHP免费学习笔记（深入）”；
