Запросы к веб-приложению Django висят;простые советы по отладке? - PullRequest
0 голосов
/ 13 января 2011

Обновление - решено

Проблема оказалась в том, что серверы имели монтирование, указывающее на файловый сервер, который был удален ранее на этой неделе; так что никак не связано с 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

1 Ответ

3 голосов
/ 13 января 2011

Следует упомянуть лишь несколько моментов:

  • Вам следует постараться как можно скорее отказаться от использования mod_python, поскольку его использование устарело и не будет поддерживаться django в будущем.
  • Можете ли вы воспроизвести проблемы, используя сервер разработки?
  • Можете ли вы воспроизвести его, используя другой сервер базы данных?
  • Попробуйте использовать django-debug-toolbar чтобы проверить, не возникают ли слишком сложные запросы к базе данных или похожие проблемы!
  • Строка в журнале ошибок не указывает на ошибку !
...