如何在本地用Python应用运行测试Gunicorn并复现流水线signal 9报错

1. 修复gunicorn命令不存在的问题 #

• 该问题基本都是依赖环境隔离导致的，Python项目通常用虚拟环境拆分不同项目的依赖，全局安装的Gunicorn无法在项目虚拟环境中调用，反之同理。
• 操作步骤：
  • 先激活项目对应的虚拟环境，再执行pip install -r requirements.txt重新全量安装项目依赖
  • 执行pip show gunicorn确认Gunicorn安装成功，再通过which gunicorn（Linux/macOS）或where gunicorn（Windows）确认命令路径与当前激活的虚拟环境路径匹配
  • 如果仍无法调用，可直接用虚拟环境的绝对路径执行，比如虚拟环境存放在项目根目录venv文件夹下时，调用命令为./venv/bin/gunicorn

2. 项目无Gunicorn导入代码的说明 #

Gunicorn是独立的WSGI服务器，不需要在业务代码中导入引用，它的作用是拉起你的Python Web服务进程。你可以在项目的部署配置文件中找到相关启动参数，常见的配置文件包括Dockerfile、流水线配置文件（如.gitlab-ci.yml/Jenkinsfile）、自定义部署脚本，启动时通常会通过-c config.py参数加载你找到的config.py配置文件。

3. Worker terminated due to signal 9报错的排查与复现 #

• 报错根因：signal 9对应Linux系统的SIGKILL信号，绝大多数情况是系统内存不足时，OOM Killer主动杀掉了内存占用过高的Gunicorn worker进程。流水线环境的资源配额通常远低于本地开发环境，这也是为什么流水线报错但本地直接跑服务不会触发问题。
• 本地复现方法：
  • 先从流水线配置中提取完整的Gunicorn启动命令，本地用完全相同的参数、配置文件启动服务
  • 可通过两种方式触发报错：一是用ab、locust等压测工具给服务加压，抬高内存占用；二是手动限制本地进程的内存上限，比如Linux系统下执行ulimit -m 内存上限值后再启动服务，模拟流水线的低内存环境
• 修复方案：
  • 调低Gunicorn的worker数量，通用配置规则为worker数=CPU核心数*2+1，流水线CPU核心通常较少，可先设置为1-2个验证
  • 排查业务代码的内存泄漏问题，降低单进程的内存占用
  • 若确认是流水线资源不足，联系运维调整流水线的内存配额

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