workers.count必须手动设，因默认CPU核数×2易致OOM：8线程×128M内存限制已达1GB，叠加OPcache、autoload等实际占用高30%～50%，8GB服务器直接启用16线程常被系统kill；须按workers.count×memory_limit＜可用内存反推上限并压测调优。
FrankenPHP 的 workers.count 和 max_threads 不是并列参数，而是“常驻池 + 弹性上限”的关系：前者必须显式设，后者只在突发流量时兜底，且二者之和才是真实线程总数上限。
为什么 workers.count 必须手动设，不能依赖默认值
FrankenPHP 默认按 CPU 核心数 × 2 启动线程（如 4 核 → 8 线程），但这只是冷启动安全值。真实场景中它极易触发 OOM：
– 每个线程受 memory_limit 约束，8 × 128M = 1GB 内存仅用于 PHP 执行上下文；
– 加上 OPcache、Composer autoload classmap、框架实例等，实际内存占用常比配置高 30%～50%；
– 8GB 内存服务器若直接用默认 16 线程，很可能压测中途被系统 kill。
必须按 workers.count × memory_limit < 可用内存 反推上限，再结合压测数据调优。
max_threads 不是“越多越好”，它是防雪崩的保底线
max_threads 是运行时可额外拉起的线程数（不含 workers.count），例如 workers.count=4、max_threads=12，意味着最多只允许再加 8 个线程，总数封顶 12。
常见误配：
– 设成 64 或 128，结果 frankenphp_busy_threads 长期满载但 frankenphp_queue_depth 持续上涨——线程太多导致上下文切换开销暴涨、Go runtime 调度失衡；
– 容器环境 CPU 受限后仍设高 max_threads，frankenphp_total_threads 达几十，但 frankenphp_busy_threads 却卡在 1～2，其余全在 S 状态排队等调度；
正确做法：
– I/O 密集型应用（大量 MySQL/Redis 调用）可设 max_threads = workers.count + 4，并配 max_wait_time 防雪崩；
– CPU 密集型建议 max_threads ≤ workers.count，甚至禁用自动扩容（设为 0）；
– 容器内务必设 max_threads = workers.count + 2，只允许临时加 2 个线程扛毛刺。
怎么验证当前 workers.count 和 max_threads 是否合理
别只看平均延迟或 RPS，重点盯三个信号：
– 用 curl http://localhost:2019/metrics | grep frankenphp_total_threads 查总线程数，再对比 frankenphp_busy_threads 占比：长期 ≤ 0.5 且 frankenphp_queue_depth > 0 → workers.count 太小；
– watch -n 1 'ps aux | grep frankenphp-worker | wc -l' 观察 worker 进程数是否稳定（波动 ±1 正常，持续增减说明配置冲突）；
– watch -n 1 'ps aux --sort=-%mem | head -5' 看单个 frankenphp-worker 进程内存是否逼近 memory_limit；
– 压测中出现 Allowed memory size exhausted 错误 → workers.count × memory_limit 已越界，必须调低任一参数；
– wrk 显示 99% 延迟暴涨但平均延迟变化不大 → 典型线程过载，请求在队列里等线程，此时加 workers.count 能直接缓解，但必须同步检查内存是否兜得住。
立即学习“PHP免费学习笔记（深入）”；
最易被忽略的一点：线程数翻倍后，OPcache 是每个线程独立的。若没预热或 opcache.validate_timestamps 没关，新线程加载类时频繁触发哈希表淘汰，QPS 反而下降。调完 workers.count 后，必须执行 frankenphp php-cli -r "opcache_reset();" 并确认 opcache.max_accelerated_files ≥ 20000。
