一个每月提供大约 950k 页面浏览量的 Django 站点（托管在 Webfaction 上）正在经历崩溃，我无法弄清楚如何调试。以不可预测的时间间隔（平均每天一次，但不是每天同一时间），对站点的所有请求都开始挂起/超时，使得站点完全无法访问，直到我们重新启动 Apache。这些请求在前端访问日志中显示为 499，但根本不会出现在我们应用程序的日志中。
在仔细研究服务器日志（包括由 django-timelog 生成的日志）时，我似乎找不到任何在网站关闭之前就点击页面的模式。对于最近的崩溃，在网站关闭之前被击中的所有页面似乎都是标准的“渲染到响应”操作，使用的模板看起来非常简单，并且在其余时间运行良好。根据时间日志，崩溃前的请求似乎不需要更长的时间，而且我无法通过负载测试故意复制崩溃。
Webfaction 说这不是超出我们允许的内存使用量的情况，否则他们会通知我们。需要注意的一件事是，当我们恢复站点时，数据库并没有重新启动（只是应用程序/Apache）。
您将如何调查此类反复出现的问题？似乎必须有一行代码挂在某个地方——你对找到它的过程有什么建议吗？
我曾经遇到过这样的问题，基本上归结为我对 django 中间件中的线程安全的误解。基本上，django 中间件是我相信在所有线程之间共享的单例，并且这些线程正在与我拥有的自定义中间件类上设置的值发生冲突。我的解决方案是重写我的中间件以不使用已更改的实例或类属性，并将我的应用程序的关键部分切换为根本不使用我的 uwsgi 服务器的线程，因为这些似乎是我的应用程序的整体性能下降。当您的视图可能以不同的时间间隔完成（一些长时间运行的视图和一些快速运行的视图）时，线程化 uwsgi 设置似乎工作得最好。
由于在复制崩溃之前您无法真正描述故障条件，因此您可能需要使用ab（apache benchmark）强制这种情况。如果您不想对您的生产站点执行此操作，您可以在子域中复制该站点。警告：ab可以击败服务器中永远爱的废话，所以 RTM。您可能还希望让 WF 管理员提前了解您将要做什么。
更新评论：
我建议使用完全相同的机器，以便子域名是唯一的区别。鉴于您使用了不同的机器，有大量微妙的（而不是那么微妙的）环境因素可能会使您远离让错误显现出来。如果新机器没问题，并且如果您愿意在不实际解决问题的情况下摆脱问题，那么您可能只需将其用作生产机器并感到高兴。就我个人而言，我倾向于沉迷于这样的事情，但话说回来，我也退休了，有足够的时间玩我的脚趾。:-)