Django Webアプリケーションへのリクエストがハングアップしています。簡単なデバッグのヒント？

Question

アップデート - 問題は、今週初めに引退したファイルサーバでマウントポインティングを持っていたサーバであることが判明し

を解決しました。結局、django/mod-python/etcには関係しません。マウントを更新すると問題が解決しました。野生のガチョウの追跡のためのコメント&ヘルプ、および謝罪のため

多くのおかげで...私は

概要

I :-)どのような場合にはMOD-pythonのをオフにアップグレードするに見ていきます数日前まで正常に動作していたDjango webappを維持していましたが、今ではすべてのWebリクエストがちょうどハングアップしています。私は何かが変わったことに気づいていないので、問題はおそらくかなり単純です。

私はWebサーバーを再起動し、httpdを再起動しようとしました。 'top'は、サーバーがCPUとメモリを正常に処理していることを示します。

誰かが間違っている可能性のある他の簡単なことや他のものを確認することはできますか？

詳細

私は、Webサーバーを作成していないので、残念ながら、私は完全な詳細の完全わからないんだけど、または私は、Webサーバーが知っている場所など、すべてのログを検索する場所Djangoを使って実装されています。 Linuxサーバー上で動作します。 PostgreSQLデータベースを使用します。静的コンテンツのlighttpd。 Apacheは着信HTTPリクエストを処理し、mod_python経由でDjangoに渡します。レンダリングされたページをキャッシュするためにmemcachedを使用します。私はLinuxサーバーとデータベースに完全にアクセスできるので、見た目を知っていれば、何かを喜ばせることができます。

/var/log/httpd/access_logとerror_logは、新しいリクエストを行うたびに次のような行を表示します。私はmod_pythonの行がエラーを示しているかどうかわかりません（何もわかりませんが、私はこのログを探知しました）。

のaccess_log：

127.0.0.1 - - [13/Jan/2011:10:56:11 +0000] "GET /testruns/testrun2176/ HTTP/1.0" 301 - "http://myapp/testruns/" "Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 (.NET CLR 3.5.30729; .NET4.0E)" 

のerror_log：

[Thu Jan 13 10:34:19 2011] [notice] mod_python: (Re)importing module 'django.core.handlers.modpython' 

出力開発サーバー

# python manage.py runserver 0.0.0.0:8088 
Validating models... 
0 errors found 

Django version 1.0-final-SVN-unknown, using settings 'myapp.settings' 
Development server is running at http://0.0.0.0:8088/ 
Quit the server with CONTROL-C. 
[13/Jan/2011 14:23:31] "GET /testruns/testrun2176/ HTTP/1.1" 301 0 

を実行しているから、その後何も起こりません。ウェブページが読み込みに失敗しました。

少し簡単なページのいずれかを読み込むことができます。 devのバージョンでは、画像はロードされませんが、それ以外は問題ありません。シンプルなページがある時/ testruns/- 何らかの理由で、私はそのrunserver出力で、そのページが表示されないにもかかわらず：

# python manage.py runserver 0.0.0.0:8088 
Validating models... 
0 errors found 

Django version 1.0-final-SVN-unknown, using settings 'myapp.settings' 
Development server is running at http://0.0.0.0:8088/ 
Quit the server with CONTROL-C. 
[13/Jan/2011 14:27:42] "GET /static/myapp.css HTTP/1.1" 404 1113 
[13/Jan/2011 14:27:42] "GET /static/myapp_print.css HTTP/1.1" 404 1113 
[13/Jan/2011 14:27:42] "GET /static/myapp_ticks_crosses.css HTTP/1.1" 404 1113 

私は再び指摘しなければならないが、これはすべての作業罰金数日前のことでした。それ以来何も明示的に変更していません - 必要なページが読み込まれないことが突然見つかったので、その理由を調べようとしています。

/var/log/httpd/logファイルは特に興味深いものを表示していないようですが、私はそれ以外の点についてはわかりません。

異なるテスト結果セットで動作する第2のサーバーを実行しています。開発サーバーを実行すると、301リダイレクトが期待されることが示されます（.../testrunX/.../testrunX/broken/page1 /にリダイレクトされます）。

// This trace, on a different server but with a similar setup, shows that the 
// 301 redirect is expected, and is not the source of the problem 
[server2]# python manage.py runserver 0.0.0.0:8088 
Validating models... 
0 errors found 

Django version 1.0-final-SVN-unknown, using settings 'myapp.settings' 
Development server is running at http://0.0.0.0:8088/ 
Quit the server with CONTROL-C. 
[13/Jan/2011 14:47:59] "GET /testruns HTTP/1.1" 301 0 
[13/Jan/2011 14:47:59] "GET /testruns/ HTTP/1.1" 200 11568 
[13/Jan/2011 14:47:59] "GET /static/myapp.css HTTP/1.1" 404 1131 
[13/Jan/2011 14:47:59] "GET /static/myapp_print.css HTTP/1.1" 404 1131 
[13/Jan/2011 14:47:59] "GET /static/star.png HTTP/1.1" 404 1131 
[13/Jan/2011 14:47:59] "GET /static/myapp_ticks_crosses.css HTTP/1.1" 404 1131 
[13/Jan/2011 14:47:59] "GET /static/star.png HTTP/1.1" 404 1131 
[13/Jan/2011 14:48:02] "GET /static/star.png HTTP/1.1" 404 1131 

[13/Jan/2011 14:48:12] "GET /testruns/testrun1879/ HTTP/1.1" 301 0 
[13/Jan/2011 14:48:12] "GET /testruns/testrun1879/broken/page1/ HTTP/1.1" 200 309477 
[13/Jan/2011 14:48:12] "GET /static/myapp.css HTTP/1.1" 404 1131 
[13/Jan/2011 14:48:12] "GET /static/myapp_print.css HTTP/1.1" 404 1131 
[13/Jan/2011 14:48:13] "GET /static/myapp_ticks_crosses.css HTTP/1.1" 404 1131 

私は無限ループはないと思います。何らかの理由でリクエスト/データベースのクエリ/その他のものが長すぎるか、完全に止まっています。悪いサーバー上の

memcachedの情報

memcachedのはかなり空のようです。しかし、Webリクエストが失敗した場合、つまりキャッシュに戻されるものがない（キャッシュの有効期限は12時間です）場合は、おそらく予想されます。

悪いサーバー：

// Top - only using 6K memory (VIRT) 
PID USER  PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 
30743 nobody 15 0 6640 4972 476 S 0.0 1.9 0:00.01 memcached 

// memcache-top from http://code.google.com/p/memcache-top/ 
// only using 0.2% available space 
memcache-top v0.6  (default port: 11211, color: on, refresh: 3 seconds) 
INSTANCE    USAGE HIT % CONN TIME EVICT/s READ/s WRITE/s 
127.0.0.1:11211   0.2% 0.0% 5  0.8ms 0.0  2  161 
AVERAGE:    0.2% 0.0% 5  0.8ms 0.0  2  161 
TOTAL:   111.0KB/ 64.0MB   5  0.8ms 0.0  2  161 

良いサーバー：

// Top - using ~68K memory (VIRT) 
    PID USER  PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 
2503 nobody 15 0 67900 8256 396 S 0.0 3.2 0:01.68 memcached 

// memcache-top - using 63% space 
memcache-top v0.6  (default port: 11211, color: on, refresh: 3 seconds) 
INSTANCE    USAGE HIT % CONN TIME EVICT/s READ/s WRITE/s 
127.0.0.1:11211   63.2% 0.0% 3  1.2ms 0.0  0  0 
AVERAGE:    63.2% 0.0% 3  1.2ms 0.0  0  0 
TOTAL:   40.5MB/ 64.0MB   3  1.2ms 0.0  0  0 

Answer 1

言及するだけでいくつかの点：

• あなたは離れて、できるだけ早くでmod_pythonを使用してから取得しようとする必要があり、その使用法は廃止されており、将来はdjangoでサポートされないためです。
• 開発サーバーを使用して問題を再現できますか？
• 別のデータベースバックエンドを使用して再現できますか？
• django-debug-toolbarを使用して、複雑すぎるデータベースクエリや同様の問題が発生していないかどうかを確認してください。
• エラーログの行doesn't indicate an error！