Django+Gunicorn应用高CPU致宕机：配置与性能优化咨询

1. 如何配置Gunicorn以实现每秒处理100+请求？ #

• 合理设置Worker数量：Django属于IO密集型应用（大量时间消耗在数据库查询、缓存读写或外部API调用），建议采用2*CPU核心数 + 1的公式计算。以你当前4核CPU为例，可设置9个worker。同时要结合内存情况，每个Django worker通常占用100-300MB内存，8GB内存足以支撑9个worker运行。
• 使用异步Worker类型：启用gevent或eventlet异步worker，能在IO等待时释放CPU处理其他请求，大幅提升并发能力。示例启动命令：

  gunicorn --worker-class=gevent --workers=9 --worker-connections=1000 myproject.wsgi
  

  其中--worker-connections设置单个worker能处理的并发连接数，建议设为1000左右。
• 优化Worker运行参数：
  • 设置--timeout=30：避免长时间阻塞的请求占用worker资源。
  • 设置--max-requests=1000：每个worker处理1000个请求后自动重启，防止内存泄漏。
  • 设置--max-requests-jitter=200：随机调整重启时机，避免所有worker同时重启导致服务波动。
• 配合前置优化：将静态资源交给Nginx处理，不要让Gunicorn承担；用Redis等缓存工具缓存数据库查询结果、页面片段，减少请求处理耗时，间接提升QPS。

2. 处理每秒100请求所需的系统规格是什么？ #

系统规格取决于请求类型和单请求处理耗时：

• 普通动态请求（已优化缓存）：若单请求响应时间在100-200ms区间，当前4核CPU+8GB内存的规格，配合合理的Gunicorn配置（异步worker+合适的worker数量），足以支撑100QPS。
• 复杂计算/重IO请求：如果请求包含大量计算或频繁数据库读写，建议升级至8核CPU+16GB内存，同时搭配异步worker和缓存优化，确保资源充足。
• 核心参考公式：QPS = 总Worker数 / 单请求响应时间（秒）。比如单请求耗时0.1秒，10个worker就能达到100QPS；若耗时0.2秒，则需要20个worker，此时要确保内存能承载对应数量的worker。

3. Gunicorn的worker数量是否等于CPU核心数？ #

不是绝对的，需根据应用类型调整：

• CPU密集型应用：比如大量数据计算的服务，worker数量建议等于CPU核心数，避免过多worker导致CPU上下文切换频繁，浪费资源。
• IO密集型应用（如Django）：worker数量应大于CPU核心数，通常采用2*CPU核心数 +1的公式。因为这类应用的worker大部分时间处于IO等待状态，多开worker能充分利用空闲的CPU资源，提升并发能力。
• 内存限制优先：无论哪种场景，都不能盲目增加worker数量，需结合服务器内存计算——每个worker占用的内存总和不能超过可用内存的70%，避免系统内存耗尽导致宕机。

内容的提问来源于stack exchange，提问作者Shahin Salim