说明所有线程均处于i/o等待或阻塞状态，并非真忙于cpu计算；此时加线程会加剧排队与内存压力，而非提升吞吐，需排查curl超时、db连接耗尽、文件锁等外部依赖问题。
frankenphp_busy_threads长期≈frankenphp_total_threads说明什么
这表示所有线程都处于“忙”状态，但不是真在执行 CPU 计算——大概率卡在 I/O 等待（如未设超时的 curl、数据库连接等待、文件锁、DNS 查询）或内部阻塞（如 OPcache 写锁、session 文件争用）。此时增加线程只会让排队更深，而不是加快处理。
关键指标要一起看：frankenphp_queue_depth 持续 > 0 + frankenphp_threads_busy/frankenphp_threads_total > 0.8，就是典型的“假高负载”：CPU idle 很高，但请求堆在队列里出不去。
用 htop -p $(pgrep -f frankenphp) 观察线程状态：如果大量显示 S（sleep），基本可排除 CPU 瓶颈，问题在外部依赖或同步阻塞点。
max_threads设太高直接触发OOM的链路
FrankenPHP 的每个 PHP 线程是 OS 级线程，启动即分配栈空间（默认 2MB+），加上 OPcache、框架 autoload、静态类实例等，实测 Laravel 项目单线程常驻内存约 25–40MB。设 max_threads 64，光线程本身就能吃掉 1.5GB+ 内存，还没算 PHP 请求峰值内存和 Go runtime 开销。
容器场景更危险：Docker 的 -m 限制的是整个进程组，memory_limit 只管单请求，两者不联动。OOM Killer 会在内存超限时直接杀主进程，连日志都不留。
-
num_threads × memory_limit必须 - 禁用
max_threads auto—— 它会让 FrankenPHP 在突发流量下无限创建线程，等于主动触发雪崩 - 若必须设较高
max_threads（如 I/O 密集型服务设到 32），务必配max_wait_time，否则排队请求在等新线程时就已超时
线程太多导致Go runtime调度失衡的真实表现
FrankenPHP 底层用 Go 编写，PHP 线程由 Go runtime 管理。线程数远超 CPU 核心数时，Go 的 M:N 调度器会频繁做上下文切换，反而压低有效吞吐。你看到的现象可能是：
— curl 请求卡住，但 strace -p $(pgrep frankenphp) 显示大量 futex 等待
— frankenphp_total_threads 上去后，frankenphp_busy_threads 增长变缓甚至停滞
— dmesg 出现 Out of memory: Kill process，但 free -h 显示还有空闲内存（被内核页表/Slab 占满）
这不是配置没生效，是 Go runtime 已经在调度层面扛不住了——它宁可让请求排队，也不愿再调度新线程。
加线程不如加实例的根本原因
FrankenPHP 是无状态进程，天然适合水平扩展。同一台机器上跑 2 个 FrankenPHP 实例（各配 num_threads 8），比单实例配 num_threads 16 更稳、更省内存、更容易隔离故障。
横向扩实例的好处是：
- 每个实例的内存 footprint 可控，OOM 不会波及其他服务
- Go runtime 调度压力分散，
frankenphp_queue_depth更容易压下来 - 配合 Caddy 的 upstream 轮询，能自然实现请求级负载均衡
真正需要调高线程数的场景极少，仅限：单实例已占满 CPU、且确认瓶颈纯在 PHP 执行（非 I/O）、同时内存充足——这种情况下才考虑把 num_threads 小幅提到 CPU 核数的 1.2～1.5 倍，max_threads 严格控制在 num_threads × 2 以内。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
