uWSGI 2.0.17+Django2.0.3 Worker偶发崩溃，请求失败率1.6%求助

看到你遇到的问题了——Docker环境里的uWSGI worker随机被信号9杀死，导致1.6%的请求失败。信号9（SIGKILL）几乎都是系统内存不足时，OOM Killer（内存不足杀手）主动终止进程的表现，当然也可能和资源限制、旧版本bug有关，咱们一步步来排查解决：

第一步：先确认是不是OOM Killer搞的鬼 #

信号9是系统强制杀死进程的信号，只有当内存耗尽时才会触发。你可以做这两件事：

• 在宿主机执行 dmesg | grep -i oom，看看有没有类似「Out of memory: Killed process 108 (uwsgi)」的日志，这是最直接的证据。
• 检查Docker容器的内存配置：启动容器时有没有用--memory限制内存？或是docker-compose里设置了mem_limit？如果给的内存太小（比如低于512MB），Django+uWSGI的worker很容易占满内存触发OOM。

第二步：调整uWSGI配置，避免内存过载或泄漏 #

针对你的uwsgi.ini，建议添加/调整几个关键参数：

• max-requests = 1000：让每个worker处理1000个请求后自动重启，防止内存泄漏累积（Django第三方库或业务代码偶尔会出现内存泄漏）。
• reload-on-rss = 256：当worker的RSS内存超过256MB时自动重启，提前换掉快要内存溢出的worker，不让系统动手。
• 合理设置workers和threads数量：如果容器内存有限，别开太多worker（比如2核CPU最多开2-4个worker，每个worker配2-4线程），过多进程会抢占内存资源。

示例调整后的uWSGI配置片段：

[uwsgi]
# 你的现有基础配置...
workers = 2
threads = 4
max-requests = 1000
reload-on-rss = 256
master = true
vacuum = true

第三步：排查代码层面的内存泄漏 #

如果调整配置后问题依旧，可能是Django代码或依赖存在内存泄漏：

• 定期执行ps aux | grep uwsgi查看worker的内存占用，如果某个worker的内存持续增长不下降，大概率是代码里有泄漏点（比如全局变量累积、未关闭的数据库连接/文件句柄）。
• 可以用Python内置的tracemalloc工具在Django中添加内存监控，定位具体的泄漏位置。

第四步：升级uWSGI版本 #

你当前使用的uWSGI 2.0.17是2018年的旧版本，里面存在不少已知的进程管理、内存相关bug。升级到最新的2.0.x稳定版（比如2.0.21），很多旧版本的内存泄漏或进程崩溃问题已经被修复。

第五步：优化Docker资源配置 #

• 给容器分配足够内存：如果你的Django应用比较复杂，至少分配1GB以上内存，同时开启适量swap（Docker默认可能禁用swap，启动容器时可以加--memory=1g --memory-swap=2g参数）。
• 避免过度限制CPU：如果容器CPU被限制过死，worker可能因无法及时处理请求导致内存堆积，间接触发OOM。

最后提醒：优先从OOM Killer的排查入手，这是此类问题最常见的原因。如果dmesg里有OOM相关记录，先调整容器内存和uWSGI的worker数量/重启策略。

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