mysql - 我该如何调查这些神秘的 Django 崩溃？

Question

一个 Django 站点(托管在 Webfaction 上)每月提供大约 950,000 个页面浏览量，但我一直无法弄清楚如何调试。在不可预知的时间间隔内(平均大约每天一次，但并非每天都在同一时间)，对站点的所有请求都开始挂起/超时，导致站点完全无法访问，直到我们重新启动 Apache。这些请求在前端访问日志中显示为 499，但根本不会出现在我们的应用程序日志中。

在仔细研究服务器日志(包括那些由 django-timelog 生成的日志)时，我似乎无法找到任何在站点关闭之前点击页面的模式。对于最近的崩溃，所有在站点崩溃之前被点击的页面似乎都是使用模板的标准渲染到响应操作，这些模板看起来非常简单并且在其余时间运行良好。根据时间日志，崩溃前的请求似乎不会花费更长的时间，而且我无法通过负载测试有意地复制崩溃。

Webfaction 表示这不是超出我们允许的内存使用量的情况，否则他们会通知我们。需要注意的一件事是，当我们恢复站点时，数据库不会重新启动(只是应用程序/Apache)。

您将如何着手调查此类反复出现的问题？似乎一定有一行代码卡在某个地方 - 您对找到它的过程有什么建议吗？

Answer 1

我曾经有过这样的问题，基本上归结为我对 django 中间件中线程安全的误解。基本上，我相信 django 中间件是一个在所有线程之间共享的单例，并且这些线程正在使用我拥有的自定义中间件类上设置的值进行抖动。我的解决方案是重写我的中间件以不使用更改的实例或类属性，并将我的应用程序的关键部分切换为完全不使用我的 uwsgi 服务器的线程，因为这些似乎是我的应用程序的整体性能下降。当您的 View 可能以不同的时间间隔完成(一些长时间运行的 View 和一些快速运行的 View )时，线程 uwsgi 设置似乎效果最好。