Django+Gunicorn部署ods数据导入时出现网关超时问题求助

嘿，我之前在小内存服务器上部署Django时也碰到过类似的长请求超时问题，结合你的场景（1GB内存的Digital Ocean Droplet），咱们从几个核心方向排查解决：

1. 调整Nginx的请求超时配置 #

Nginx默认的请求超时时间通常比较短（比如60秒），而你的ODS导入即使每100行休眠2秒，处理几千行的总时间很容易超过这个阈值，导致Nginx直接返回网关超时。

修改你的Nginx站点配置文件（一般在/etc/nginx/sites-available/下），在反向代理的location块里添加超时参数：

location / {
    proxy_pass http://127.0.0.1:8000; # 对应你的Gunicorn监听地址
    proxy_connect_timeout 300s;
    proxy_read_timeout 300s;
    proxy_send_timeout 300s;
}

修改后重启Nginx生效：

sudo systemctl restart nginx

2. 优化Gunicorn的Worker配置 #

1GB内存的服务器扛不住太多Gunicorn Worker，默认的Worker数量（通常是2*CPU核心数+1）可能会导致内存过载，进而中断请求。

调整Worker数量 #

对于1GB内存的Droplet，建议先把Worker数量降到1-2个，同时可以开启Threads提升并发能力：

gunicorn --workers=1 --threads=4 --timeout=300 your_project.wsgi:application

如果用配置文件管理Gunicorn，在gunicorn.conf.py里添加：

workers = 1
threads = 4
timeout = 300

关键参数说明 #

• --timeout=300：确保Gunicorn不会因为请求耗时过长（比如5分钟）而主动杀死Worker进程
• --threads=4：在单个Worker进程内开启多线程，在内存有限的情况下提升处理效率

3. 优化ODS解析的内存占用 #

虽然开发服务器能跑，但生产环境的内存限制更严格，要确保你的ODS解析逻辑是流式逐行处理，而不是一次性把整个文件加载到内存：

• 检查你用的ODS解析库（比如pyexcel-ods、odfpy），优先使用支持迭代器的API，逐行读取和处理数据，不要把所有行存入列表
• 处理完每一行后，及时释放不再需要的变量，避免内存泄漏
• 你的每100行休眠2秒的逻辑可以保留，但要确保用的是time.sleep(2)，且配合Gunicorn的timeout参数，防止Worker被判定为超时

4. 进阶：异步化长耗时导入任务 #

数据导入属于典型的长耗时任务，放在同步请求里处理始终有超时风险，更优雅的方案是用异步任务框架剥离这个逻辑：

• 用Celery配合Redis（1GB内存的Droplet完全能运行Redis），将导入任务异步化
• 用户上传ODS文件后，后端立即返回“导入任务已提交”，然后由Celery Worker在后台处理导入
• 可以在Django里添加任务进度查询接口，让用户查看导入状态

这样既彻底解决了网关超时问题，也不会占用Web服务器的Worker资源，提升整体服务稳定性。

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