Обновление - решено
Проблема оказалась в том, что серверы имели монтирование, указывающее на файловый сервер, который был удален ранее на этой неделе; так что никак не связано с django / mod-python / etc. Обновление монтирования решило проблему.
Большое спасибо за комментарии и помощь, и извинения за погоню за диким гусем ... В любом случае я рассмотрю обновление с mod-python: -)
Резюме
Я поддерживаю веб-приложение Django, которое работало хорошо несколько дней назад, но теперь все веб-запросы просто зависают целую вечность. Я не знаю, что что-то изменилось, так что проблема, вероятно, довольно проста.
Я попытался перезапустить веб-сервер и перезапустить httpd. 'top' показывает, что сервер работает нормально с процессором и памятью.
Может кто-нибудь предложить другие простые вещи, которые могут пойти не так, или другие вещи, чтобы проверить?
Подробнее
Я не создавал веб-сервер, поэтому, к сожалению, я не совсем уверен в полной информации или в том, где искать все журналы и т. Д. Я знаю, что веб-сервер состоит из следующих компонентов: реализованных с использованием Django ; работает на сервере Linux; использует базу данных PostgreSQL; lighttpd для статического контента; Apache для обработки входящих HTTP-запросов и передачи их в Django через mod_python; использует 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, кажется, не показывают ничего особенно интересного, и я не уверен, что еще мне следует посмотреть.
Мы запускаем второй сервер, который работает с другим набором результатов тестирования. Запуск сервера разработки на этом показывает, что ожидается перенаправление 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 info
memcached на плохом сервере кажется довольно пустым. Но это, вероятно, ожидаемо, если веб-запросы терпят неудачу, то есть ничего не возвращено для хранения в кеше (и срок действия кеша составляет 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