max_threads不是越大越好，它指运行时可额外拉起的线程上限（不含num_threads），如num_threads=4、max_threads=12时最多新增8个线程；需按CPU核数与I/O特征设定，I/O密集型可设32但须配max_wait_time防雪崩，CPU密集型建议≤num_threads，禁用auto以防OOM。

max_threads 不是“越大越好”，它和 num_threads 是两回事

很多人一看到“最大线程数”就直接设成 64、128，结果服务跑半天就 OOM 或卡死。根本原因是混淆了 num_threads（常驻线程池）和 max_threads（运行时可额外拉起的线程上限）。max_threads 不包含 num_threads，比如你设 num_threads 4、max_threads 12，那最多只允许再加 8 个线程，总数封顶 12。

更关键的是：max_threads 控制的是“紧急扩容能力”，不是“并发承载能力”。线程太多反而导致上下文切换开销暴涨、内存吃紧、Go runtime 调度失衡——你看到 frankenphp_busy_threads 满了但 frankenphp_queue_depth 还在涨，大概率就是这个原因。

怎么定具体数值：看 CPU 核心数 + I/O 特征，不是看 QPS

FrankenPHP 的 PHP 线程是 OS 级线程，每个都绑定调度权。盲目堆数量不会提升吞吐，只会放大争用。推荐按以下组合起步：

• 服务器有 8 核？num_threads 设 8～16，max_threads 就设 16～24（即 num_threads × 2 左右）
• 应用大量调用外部 API 或数据库（I/O 密集型）？可放宽到 max_threads 32，但必须配 max_wait_time 5s 防止排队雪崩
• 纯 CPU 密集型（如图像缩放、加密计算）？max_threads 建议 ≤ num_threads，避免核间抢资源
• 绝对不要设 max_threads auto：它等于放弃控制，突发流量下极易触发 OOM Killer 杀进程

不设或设太大会出什么问题？这些现象你可能已经见过

常见错误表现不是“502 Bad Gateway”，而是更隐蔽的性能坍塌：

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

立即学习“PHP免费学习笔记（深入）”；

• curl 请求卡住、超时，但 frankenphp_busy_threads 显示全忙，frankenphp_total_threads 却远低于预期
• frankenphp_queue_depth 持续上涨，Caddy 日志里出现 timeout waiting for php thread
• 系统 load average 很高，但 top 里 CPU idle 却 >70%，dmesg 打印 Out of memory: Kill process
• 每个 PHP 线程吃掉 30MB+ 内存，max_threads 64 在 Laravel 项目里轻松干掉 2GB RAM

验证配置是否合理：盯住三个指标，别光看日志

上线后别只盯着访问是否成功，重点观察运行时指标：

• frankenphp_total_threads 和 frankenphp_busy_threads 的差值是否长期为 0？如果是，说明线程全在等 I/O 或锁，不是真忙，max_threads 再大也没用
• frankenphp_queue_depth 是否稳定在个位数？持续 >10 就得查是不是 max_wait_time 太短或后端响应慢
• 进程 RSS 内存是否逼近容器或 systemd 设置的硬上限？比如容器 mem_limit: 512m，但 FrankenPHP 进程 RSS 经常 >450MB，就得立刻调低 memory_limit 或 max_threads

最易被忽略的一点：线程数调得再准，如果没同步收紧 memory_limit 和容器内存限制，照样会因内存超限被杀。两者必须联动调整，不能只动一边。