2

1 か月あたり約 95 万ページビューを提供する Django サイト (Webfaction でホストされている) でクラッシュが発生しており、デバッグ方法がわかりません。予測不可能な間隔で (平均すると 1 日に 1 回ですが、毎日同じ時間ではありません)、サイトへのすべてのリクエストがハング/タイムアウトし始め、Apache を再起動するまでサイトに完全にアクセスできなくなります。これらのリクエストは、フロントエンド アクセス ログには 499 として表示されますが、アプリケーションのログにはまったく表示されません。

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

Webfaction は、許可されたメモリ使用量をオーバーランした場合ではなく、さもないと通知されると言っています。注意すべきことの 1 つは、サイトを復旧したときにデータベースが再起動されないことです (アプリ/Apache のみ)。

この種の繰り返し発生する問題をどのように調査しますか? ぶら下がっているコード行がどこかにあるようです - それを見つけるためのプロセスについて何か提案はありますか?

4

2 に答える 2

0

クラッシュを再現できるようになるまで、障害の状態を実際に説明することはできないため、ab（apacheベンチマーク）を使用して状況を強制する必要がある場合があります。本番サイトでこれを実行したくない場合は、サブドメインでサイトを複製することができます。警告：abサーバーからこれまで愛されてきたがらくたを打ち負かすことができるので、RTM。また、WF管理者に、これから行うことについて注意を喚起することもできます。

コメントの更新：

サブドメイン名が唯一の違いになるように、まったく同じマシンを使用することを提案していました。別のマシンを使用したことを考えると、エラーが顕在化するのを防ぐために、微妙な（そしてそれほど微妙ではない）環境問題が多数あります。新しいマシンに問題がなく、実際に問題を解決せずに問題から離れることをいとわない場合は、単に本番マシンにして満足することができます。個人的にはこういうことにこだわる傾向がありますが、やはり引退していて、つま先で遊ぶ時間がたくさんあります。:-)

于 2012-05-03T20:29:13.180 に答える
0

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

于 2012-05-04T02:35:54.823 に答える