AWS部署Web应用时gunicorn内存占用异常升高问题咨询

结合你给出的部署环境（AWS免费层Ubuntu 14.04.5 LTS、ELB+Nginx 1.4.6+gunicorn 19.7.1、Django 2.0.3+Angular），我整理了几个最可能导致内存异常飙升的原因，以及对应的落地解决思路：

一、Gunicorn Worker配置不合理（免费层实例最常见问题） #

AWS免费层的EC2实例（比如t2.micro）通常只有1GB内存，如果gunicorn的worker数量或参数设置不合理，会直接导致内存资源被快速耗尽。

解决方法： #

• 调整worker数量：遵循2*CPU核心数 +1的经验公式，t2.micro是1核，所以设置--workers=3足够，不要盲目增多。启动命令示例：gunicorn --workers=3 your_project.wsgi:application
• 限制worker内存累积：使用--max-requests参数让worker处理一定量请求后自动重启，避免内存泄漏累积。比如设置--max-requests=1000，每个worker处理1000个请求就重启释放内存。
• 改用异步worker类型：默认的sync worker处理IO阻塞请求时效率低、内存占用高，如果你的Django应用有数据库查询、第三方API调用等IO操作，可尝试gevent或eventlet异步worker。安装gevent后启动命令：gunicorn --workers=3 --worker-class=gevent your_project.wsgi:application

二、Django应用存在内存泄漏或低效数据处理 #

如果你的Django视图在处理请求时加载了大量数据，或存在未释放的资源，会导致每个请求都额外占用内存，累积后引发飙升。

解决方法： #

• 优化数据库查询：避免使用Model.objects.all()一次性加载全量数据，改用分页（Paginator）或只查询需要的字段（only()/defer()）。
• 排查内存泄漏：用memory_profiler或objgraph工具检测代码中的内存泄漏点。比如给视图函数加上@profile装饰器，运行测试请求后查看内存占用细节。
• 清理未释放资源：确保请求结束后关闭打开的文件、数据库连接、第三方API连接等资源，避免长期占用内存。

三、Nginx与Gunicorn的连接配置不匹配 #

如果Nginx的连接设置和gunicorn的worker连接数不匹配，会导致连接堆积，每个连接都会占用内存资源。

解决方法： #

• 调整Nginx的keepalive_timeout：建议设置为60秒左右，避免长连接过多占用资源。在Nginx的server块添加：keepalive_timeout 60;
• 调低gunicorn的--worker-connections：默认值是100，对于免费层实例可适当调低到50，避免同时处理过多连接。
• 检查Nginx转发逻辑：确保没有错误地将静态文件请求转发给gunicorn，这会大幅增加内存负担。

四、静态文件未由Nginx正确处理 #

如果Angular生成的静态文件（JS、CSS、图片）没有由Nginx直接处理，而是转发给gunicorn，gunicorn处理静态文件的效率极低，会直接引发内存飙升。

解决方法： #

• 在Nginx配置中添加静态文件路由，示例如下：

location /static/ {
    root /path/to/your/django/project;
    expires 30d;
}

location /angular/ {
    root /path/to/your/angular/dist;
    expires 30d;
}

• 确保Angular已构建为生产版本（ng build --prod），生产版本的静态文件体积更小、加载更快，能降低请求处理的内存消耗。

五、Gunicorn版本过旧存在已知bug #

gunicorn 19.7.1是2017年的老版本，存在一些已被修复的内存泄漏问题，升级版本能直接解决这类问题。

解决方法： #

• 升级gunicorn到最新稳定版本：运行pip install --upgrade gunicorn，建议升级到20.x及以上版本，这些版本对内存管理做了针对性优化。

你可以先从调整gunicorn worker配置和检查静态文件处理逻辑入手，这两个是最容易排查和快速见效的方向。如果问题仍存在，再逐步排查Django代码中的内存问题。

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