FrankenPHP Worker 内存告警阈值应设为实测95分位RSS值上浮15–20%，需基于真实流量压测24小时以上，监控frankenphp_worker_memory_bytes或系统RSS，不可依赖memory_get_usage()。
FrankenPHP Worker 进程内存告警该设多少？
没有统一的“安全值”，直接套用 128MB 或 256MB 很可能误报或漏报。Worker 是常驻进程，内存会随请求累积、缓存增长、框架初始化而缓慢上升——它不像 PHP-FPM 那样每请求重置。告警阈值必须结合你的具体 Worker 脚本行为来定。
怎么测出你自己的合理阈值？
别猜，要实测。在和生产环境一致的配置下（相同 workers.count、相同 PHP 版本、相同应用代码），用真实流量或压测工具跑够 24 小时以上，重点观察：
-
frankenphp_worker_memory_bytes{worker="your-script.php"}指标（需启用 Caddy metrics）的峰值和趋势 - 对应进程在系统层的 RSS 值（
ps aux --sort=-%mem | grep your-script.php） - 是否伴随
frankenphp_worker_restarts_total上升（说明被 OOM Killer 杀过）
取这段时间内稳定运行阶段的 **95 分位 RSS 值**，再上浮 15–20%，就是你该设的告警线。例如实测峰值常在 310MB，那就设 360MB 告警。
为什么不能只看 memory_get_usage()？
这个函数只返回 PHP 用户态分配的内存，不包括：
立即学习“PHP免费学习笔记（深入）”；
- Zend 引擎内部结构（如 opcode cache、符号表）
- 扩展（如 Redis、PDO）持有的 C 层内存
- PHP 进程加载的共享库、JIT 编译代码页
所以你在脚本里用 memory_get_peak_usage(true) 看到 180MB，系统 ps 显示 RSS 340MB 是完全正常的。监控必须以 frankenphp_worker_memory_bytes 或系统 RSS 为准，否则永远晚一步。
容易被忽略的两个关键点
一是 max_requests 参数不是万能解药：设成 1000 只能防泄漏，但无法阻止正常缓存增长导致的内存缓慢爬升；二是不同 Worker 脚本差异极大——一个纯 API 脚本可能稳在 200MB，而带图像处理的脚本启动就占 450MB。每个 worker="xxx" 标签都得单独建告警规则，混在一起看平均值毫无意义。
