Django с wsgi иногда терпит неудачу с «преждевременным концом заголовков сценария:» - PullRequest
Новая
       1

Django с wsgi иногда терпит неудачу с «преждевременным концом заголовков сценария:»

5 голосов
/ 14 ноября 2011

У меня есть сайт, который работает в течение нескольких месяцев на Apache2, и периодически он будет просто сбой со следующим: 

[Sat Nov 12 06:18:34 2011] [error] [client X.Y.Z.158] Premature end of script headers: sleepsoundly_wsgi.py
[Sat Nov 12 06:18:49 2011] [error] [client X.Y.Z.158] Premature end of script headers: sleepsoundly_wsgi.py

Он выполнил тысячи запросов без проблем, но периодически он будет делать это пару раз, и тогда все будет хорошо. Это происходит при загрузке около 300 файлов (по 0,5 МБ каждый). Каждый файл загружается отдельно, 3 файла за раз, 225 файлов загружаются нормально, 226 и 227 не удалось, а затем 228 -> end - все работало нормально. Он не делает это каждый раз, просто время от времени, и не всегда эти файлы терпят неудачу. В другой раз файл # 291 потерпел неудачу, а все остальное сработало.

У меня в журнале нет ничего, кроме этого загадочного сообщения.

Я проверил, и единственная версия python на машине - 2.7.1. Я не получаю письма от Джанго, я не получаю никаких обычных подсказок о том, что может происходить. Мне интересно, как начать устранение неполадок этого. Он восстанавливается самостоятельно, автоматическая программа загрузки файлов продолжает двигаться. Как мне выяснить, что происходит в этом случае? 

Server version: Apache/2.2.17 (Ubuntu)
Server built:   Sep  1 2011 09:25:26
mod_wsgi: Version: 3.3-2ubuntu2

Server MPM:     Prefork
  threaded:     no
    forked:     yes (variable process count)

wsgi.conf has no lines in it that are not commented out.

VirtualHost setup:
    WSGIDaemonProcess myemr user=mjones processes=1 maximum-requests=500 threads=15
    WSGIProcessGroup  myemr
    WSGIScriptAlias   / /var/www/Python/myemr/myemr/deploy/myemr_wsgi.py

myemr_wsgi.py
    from os.path import abspath, dirname, join
    import sys

    # For packages that don't play well with mod_wsgi
    sys.stdout = sys.stderr

    sys.path.insert(0, abspath(join(dirname(__file__), "../..")))
    sys.path.insert(0, abspath(join(dirname(__file__), "../../myemr")))
    sys.path.insert(0, abspath(join(dirname(__file__), "../../myemr/apps")))
    sys.path.insert(0, abspath(join(dirname(__file__), "../../lib/python2.7/site-packages/")))

    # We have to add both of these because they are  installed with git?
    sys.path.insert(0, abspath(join(dirname(__file__), "../../src/pinax/")))

    from django.core.handlers.wsgi import WSGIHandler
    import pinax.env

    # setup the environment for Django and Pinax
    pinax.env.setup_environ(project_path='myemr')

    # set application for WSGI processing
    application = WSGIHandler()

1 Ответ

5 голосов
/ 15 ноября 2011

Вероятно, проблема в том, что у вас установлено «максимум запросов», равное 500. Это приведет к периодическому перезапуску процессов демона mod_wsgi.Так как процессы демона mod_wsgi работают в многопоточной конфигурации, если был застрявший запрос или длительный запрос, который не завершается до истечения тайм-аута принудительного выключения при перезапуске, он будет прерван в силу перезапуска процесса,Дочерний рабочий процесс Apache увидит, что запрос завершается без возврата заголовков с сообщением, которое вы видите.

Мораль истории, НЕ ИСПОЛЬЗУЙТЕ опции «максимум запросов» в производственных системах, если у вас неточень веская причина, такая как неконтролируемый рост памяти.

Версия 4.0 в mod_wsgi будет иметь необязательную, но немного более изящную опцию перезапуска, которая может быть применена для этого случая, но она все еще не может ждать вечно и застрялазапрос все равно придется прервать в какой-то момент, и вы все равно увидите сообщение.

Кстати, не указывайте 'процессы = 1', так как в любом случае по умолчанию используется один процесс, и любое использование параметра 'процессы', даже со значением '1', приводит к установке 'wsgi.multiprocess'Правда.Использовать «процессы = 1» следует только в тех случаях, когда имеется один процесс И у вас много экземпляров Apache, между которыми вы балансируете нагрузку, в том числе с одним процессом.

...