使用nginx和gunicorn在AWS上发生504超时

如何解决使用nginx和gunicorn在AWS上发生504超时

我正在AWS EC2实例上运行python Django应用。它使用gunicorn和nginx为应用程序提供服务，而EC2位于应用程序负载平衡器的后面。有时，我会收到504错误，所有人都无法访问整个EC2实例（包括通过我一直使用的SSH）。然后，我需要重新启动所有花费时间的事情。

我可以通过使应用程序超载来复制错误（例如，上传和处理非常大的图像），在这种情况下，gunicorn worker超时（我在日志中看到超时消息），出现504错误并且实例变得无法访问。我将我的Gunicorn设置为在5分钟（300秒）内超时，但是它掉下来的速度比那快。 CloudWatch日志中没有真正有用的东西。

我正在寻找解决当前和未来所有情况的方法。即，我想遇到一种情况，如果该站点超载，它将返回一条错误消息，而不是每个人都无法访问。有办法吗？

解决方法

这里有很多事情需要考虑和测试，以了解其原因，但我认为这是OOM（内存不足），主要是因为您必须重新启动才能登录SSH。

Nginx使用“事件驱动”方法来处理请求，因此一个nginx工作者可以同时处理1000个请求。但是另一方面，Gunicorn通常（默认情况下）大多使用同步工作程序，这意味着在处理请求之前，请求将一直保留在工作程序中。

当您提出一个大请求时，您的计算机将尝试处理该请求，直到发生溢出为止，大多数情况下，计算机内部运行的任何服务都不会检测到该请求。只需尝试通过AWS或SSH中的任何监视工具监视内存，然后在调用API之前使用htop。

在大多数情况下，使用Django / gunicorn的罪魁祸首是oom。

编辑：

AFAIK您无法捕获（缓存）一个oom，唯一可以做的就是后果，即在系统重启后sees / var / logs / syslogs ...正如我在AWS内存监视器中所说的那样（我没有太多有AWS经验）。

关于解决方案，

• 您首先要增加EC2的内存，直到没有错误看到问题有多严重为止。

• 然后，通过分析哪一部分实际占用了这么多的内存来优化应用程序。我没有使用任何内存配置文件，因此也许您可以告诉我哪种更好。 您唯一可以做的就是优化您的应用程序，查看常见的陷阱，最佳实践，查询优化等。

https://haydenjames.io/how-to-diagnose-oom-errors-on-linux-systems/ https://www.pluralsight.com/blog/tutorials/how-to-profile-memory-usage-in-python