旧Django应用切换gevent异步Worker后性能劣化问题排查咨询

我来帮你梳理清楚这个问题——你遇到的gevent.threadpool._add_thread: can't start new thread报错，确实和大量SQL查询、模板渲染的CPU消耗直接相关，本质是gevent的协程模型和CPU密集型任务的典型冲突。

核心冲突点：gevent的协程逻辑 vs CPU密集型任务 #

gevent是基于单线程协程的异步框架，它的高并发能力完全依赖于「协程在IO阻塞时主动让出CPU」，让其他协程得以运行。但你的视图有两个致命的CPU密集型环节：

• 400次连续SQL查询：虽然单个SQL查询是IO操作，但如果用Django默认的同步ORM执行，且查询在数据库端处理较快，这些查询会连续占用CPU（因为等待IO的时间极短，协程没机会切换）；如果查询本身需要数据库做大量计算，视图处理查询结果时也会产生额外CPU消耗。
• 复杂模板渲染：这是纯CPU密集型任务，完全不会触发gevent的协程切换（没有IO阻塞点）。一旦某个协程开始渲染模板，它会死死占用当前线程的CPU，直到整个渲染完成，期间其他协程只能排队等待。

为什么会触发“无法启动新线程”报错？ #

gevent为了兼容那些无法被协程化的阻塞操作（比如某些C扩展的同步调用），内置了一个线程池作为兜底。当大量协程被CPU密集型任务卡住，无法及时完成时，gevent会不断尝试从线程池获取线程来处理积压的任务；当线程池耗尽后，它会尝试新建线程，但系统的线程数量有上限（受限于内存、系统配置），最终就抛出了can't start new thread的错误。

如何向团队解释这个情况？ #

可以用通俗的类比让大家快速理解：

把gevent的单线程协程比作一个共享一台电脑的小办公室：原本大家默认是轮流用电脑处理短任务（比如发邮件、查资料），能高效处理很多请求。但突然来了一批需要连续几小时做复杂Excel计算的任务（对应你的模板渲染+批量查询），拿到电脑的人一直占着不松手，其他人根本没法干活。办公室管理员（gevent）为了缓解拥堵，就开始找更多电脑（新建线程），但办公室的插座和空间有限（系统线程上限），最后找不到新电脑了，只能报错说“没法加新电脑了”。
而原来的同步gunicorn Worker模式，相当于每个人一台电脑，虽然能同时干活的人数有限，但每个人干自己的活，不会互相抢资源，反而不会出现这种“资源耗尽”的情况。

可行的解决方案 #

• 拆分CPU密集型任务：把模板渲染、批量SQL查询这类耗时的CPU操作，放到Celery之类的任务队列中异步处理。视图只负责触发任务，或者等待异步任务的结果（如果需要同步返回响应的话），让gevent的协程能专注处理IO密集型的请求。
• 切换到异步Django：升级到支持异步视图的Django版本（3.1+），使用异步ORM（比如async_to_sync包装异步查询，或者原生异步视图），让SQL查询的IO等待真正触发协程切换，减少对线程池的依赖。
• 调整gevent配置（治标）：临时增大gevent的线程池上限（通过GEVENT_THREADPOOL_SIZE环境变量或gunicorn配置），但这只是缓解，系统线程数终究有上限；同时可以降低gunicorn的worker数量，避免单个worker的协程过多导致线程池耗尽。
• 混合Worker模式：保留部分同步gunicorn Worker专门处理CPU密集型的视图，用gevent Worker处理IO密集型的视图，通过Nginx做路由分流，让不同类型的任务匹配最合适的Worker模型。

内容的提问来源于stack exchange，提问作者Antonio Jr. Mattos