これらの謎のジャンゴクラッシュを調べるにはどうしたらいいですか？

Question

毎月約950kページビューのDjangoサイト（Webfactionでホストされています）がクラッシュしているため、デバッグ方法がわかりませんでした。予期せぬ間隔（1日に約1回の平均で、毎日同じ時刻では平均しない）で、サイトへのすべての要求がハングアップ/タイムアウトになり、Apacheを再起動するまでサイトが完全にアクセスできなくなります。これらのリクエストは、フロントエンドのアクセスログに499として表示されますが、アプリケーションのログには表示されません。

サーバログ（django-timelogで生成されたログを含む）をポーリングすると、サイトがダウンする直前にページが表示されるパターンが見つからないようです。最近のクラッシュでは、サイトがダウンする直前にヒットしたすべてのページは、かなり単純で、残りの時間はうまくいくように見えるテンプレートを使用して、標準のレンダリング応答操作のようです。クラッシュの直前のリクエストは、タイムロッグによっては時間がかかるようには見えず、負荷テストによって意図的にクラッシュを再現することはできませんでした。

Webfactionによると、許可されたメモリ使用量を超えてしまうケースはありません。注意すべき点の1つは、サイトをバックアップするときに、データベースが再起動されていないことです（app/Apacheのみ）。

このような定期的な問題を調査するにはどうすればよいですか？どこかにコードの行がぶら下がっていなければならないようです - それを見つけるプロセスについての提案はありますか？

Answer 1

クラッシュを複製できるようになるまで、障害状態が何であるかを実際には説明できないため、状況を強制的にab（apache benchmark）にする必要があります。本番サイトでこれをしたくない場合は、サブドメイン内のサイトを複製する可能性があります。警告：abは、これまでのRTMのように、サーバーから絶え間なく愛らしいものを打ち負かすことができます。また、WFの管理者にあなたが何をしようとしているかについて頭を上げたいかもしれません。コメントを

更新：

私はサブドメイン名が唯一の違いだったようまったく同じマシンを使用して示唆されました。別のマシンを使用した場合、には、エラーが表示されないように微調整することができる微妙な（そしてそれほど微妙ではない）環境が多数あります。新しいマシンがOKで、実際に解決せずに問題から離れたい場合は、単にそのマシンをプロダクションマシンにして幸せになればよいでしょう。個人的に私はこのようなことに戸惑う傾向がありますが、やはり私も引退して、足指で遊ぶ時間があります。 :-)

Answer 2

私はかつてこのようないくつかの問題を抱えていました。それは基本的に私のdjangoミドルウェア内でのスレッドセーフの誤解です。基本的にdjangoのミドルウェアは、すべてのスレッドで共有されるシングルトンを信じています。これらのスレッドは、私が持っていたカスタムミドルウェアクラスに設定された値であいまいでした。私のソリューションは、変更されたインスタンスまたはクラスの属性を使用しないようにミドルウェアを書き直し、アプリケーションの重要な部分を私のuwsgiサーバーでスレッドをまったく使用しないように切り替えることでした。スレッド化されたuwsgiの設定は、異なる間隔で実行できるビュー（長時間実行されているビューや速いビューもあります）があるときに最適です。