Апаш + mod_wsgi, що не реагує, після встановлення scipy

10

На даний момент я працюю на сервері Centos 6.4, з Apache 2.2.15 та mod_wsgi 3.2. Сервер розміщує сайт на базі django (django 1.5.1, python 2.6.6). Все працювало нормально, поки я не встановив scipy 0.12.0 через pip. Тепер, коли я намагаюся завантажити додаток django, сервер не реагує, і, здається, що дочірні httpd-процеси, які породжуються, зависають. Переглядаючи мої журнали (/ var / logs / httpd / error_log, мій vhost error.log та мої системні журнали) не призводять до помилок.

Якщо я завантажую свої моделі тощо .. через оболонку django Manag.py, все працює добре, що призводить до того, що я вважаю, що це проблема mod_wsgi.

Будь-які думки про те, як почати вирішувати проблеми?

apache-2.2 python mod-wsgi

— MarkD
джерело

22

Деякі сторонні пакети для Python, які використовують модулі розширення C, а це включає scipy та numpy, працюватимуть лише в головному інтерпретаторі Python і не можуть використовуватися в субінтерпретаторах як mod_wsgi за замовчуванням. Результатом може стати тупикова ситуація, неправильна поведінка або збої в роботі. Вони детально описані в:

http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Python_Simplified_GIL_State_API

Вирішення проблеми полягає в тому, щоб змусити додаток WSGI запускатися в основному інтерпретаторі процесу, використовуючи:

WSGIApplicationGroup %{GLOBAL}

Якщо на одному сервері запущено кілька додатків WSGI, ви хочете почати досліджувати в режимі демона, оскільки деякі рамки не дозволяють запускати кілька екземплярів в одному інтерпретаторі. Це справа з Джанго. Таким чином, використовуйте режим демона, тому кожен веде свій процес і змушуйте кожного запускати головного інтерпретатора відповідних груп процесів у режимі демона.

— Грем Дамплетон
джерело

Привіт Грем, чи можете ви оновити цю відповідь у контексті новіших версій mod-wsgi? Зокрема, чи має це бути проблемою за замовчуванням, якщо я налаштував apache за допомогою mod_wsgi-express? У створеному httpd.confфайлі WSGIApplicationGroupне використовується. Однак є application-group=${GLOBAL}в блоках <IfDefine ONE_PROCESS>і <IfDefine !ONE_PROCESS>. Я бачу директиву WSGIDaemonProcess у створеному httpd.confфайлі. Це означає, що він вже використовує режим демона за замовчуванням?

— Кал

Якщо ви використовуєте mod_wsgi-express start-serverабо інтеграцію Django для mod_wsgi-express, вона працює за умовчанням у режимі демон та використовує основний інтерпретатор. Тож у цьому випадку це не проблема. Якщо ви вручну налаштовуєте Apache, це все ще залишається проблемою. ONE_PROCESSЧастина тільки , коли ви змушуєте його в режим налагодження, і в цьому випадку вона працює в процесі інтегрованого режимі одного. Він все ще працює в головному перекладачі.

— Грем Дамплтон

application-groupВаріант на WSGIScriptAliasце альтернатива використанню WSGIApplicationGroup.

— Грем Дамплтон

3

Ще одне рішення, яке підходило моєму способу налаштування WSGI - це зміна WSGIScriptAliasлінії:

WSGIDaemonProcess website user=user group=group python-path=/path/to/venv/website:/path/to/venv/lib/python2.7/site-packages
WSGIScriptAlias /website /path/to/venv/website/wsgi.py process-group=website application-group=%{GLOBAL}

<Location /website>
        WSGIProcessGroup website
</Location>

<Directory /path/to/venv/website>
        WSGIScriptReloading On
        <Files wsgi.py>
                Allow from all
                Require all granted
        </Files>
</Directory>

відзначте атрибути

process-group=website application-group=%{GLOBAL}

які зазвичай не потрібні

— Нілс Вернер
джерело

1

Ви можете відмовитись від директиви WSGIScriptReloading, оскільки вона за замовчуванням увімкнена, і взагалі ніколи не потрібно буде вимикатись. Завдяки використанню параметрів групи процесів для WSGIScriptAlias ви також можете скинути директиву WSGIProcessGroup.

— Грем Дамплтон