Scipy yüklendikten sonra yanıt vermeyen apache + mod

10

Şu anda Cenache 6.4 sunucusu ile Apache 2.2.15 ve mod_wsgi 3.2 kullanıyorum. Sunucu django tabanlı bir siteye ev sahipliği yapıyor (django 1.5.1, python 2.6.6). Pip yoluyla scipy 0.12.0'ı yükleyene kadar her şey iyi çalışıyordu. Şimdi, django uygulamasını yüklemeye çalıştığımda, sunucu yanıt vermiyor ve ortaya çıkan alt httpd işlemlerinin askıda kaldığı görülüyor. Günlüklerime baktığımda (/ var / logs / httpd / error_log, vhost error.log ve sistem günlüklerim) hata vermiyor.

Modellerimi vb. Yüklersem django manage.py kabuğu ile her şey yolunda gidiyor, bu da beni mod_wsgi sorunu olduğuna inandırıyor.

Bu sorunu gidermeye nasıl başlayacağınız hakkında düşünceleriniz var mı?

apache-2.2 python mod-wsgi

— MarkD
kaynak

22

C genişletme modüllerini kullanan Python için bazı üçüncü taraf paketleri ve buna scipy ve numpy dahildir, yalnızca Python ana yorumlayıcısında çalışır ve varsayılan kullanımlarda mod_wsgi olarak alt yorumlayıcılarda kullanılamaz. Sonuç, iş parçacığı kilitlenme, yanlış davranış veya işlem çökmeleri olabilir. Bunlar ayrıntılı olarak açıklanmıştır:

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

Çözüm, WSGI uygulamasını kullanarak işlemin ana yorumlayıcısında aşağıdakileri kullanarak çalışmaya zorlamaktır:

WSGIApplicationGroup %{GLOBAL}

Aynı sunucuda birden fazla WSGI uygulaması çalıştırıyorsanız, bazı çerçeveler aynı yorumlayıcıda birden çok örneğin çalışmasına izin vermediğinden, arka plan modunu kullanarak araştırmaya başlamak istersiniz. Django için durum böyledir. Böylece daemon modunu kullanın, böylece her biri kendi sürecindedir ve her birini kendi daemon modu süreç gruplarının ana yorumlayıcısında çalışmaya zorlar.

— Graham Dumpleton
kaynak

Merhaba Graham, bu cevabı mod-wsgi'nin daha yeni sürümleri bağlamında güncelleyebilir misiniz? Özellikle, mod_wsgi-express kullanarak apache yapılandırdıysam bu varsayılan olarak bir sorun olmalı mı? Oluşturulan httpd.confdosyada WSGIApplicationGroupkullanılmaz. Ancak, orada application-group=${GLOBAL}içinde <IfDefine ONE_PROCESS>ve <IfDefine !ONE_PROCESS>bloklar. Oluşturulan httpd.confdosyada bir WSGIDaemonProcess yönergesi görüyorum . Bu, varsayılan olarak zaten arka plan modunu kullandığı anlamına mı geliyor?

— Kal

Eğer kullanıyorsanız mod_wsgi-express start-serverveya Django entegrasyonu için varsayılan olarak cin modu ile çalışır ve ana tercüman kullanmak mod_wsgi-express. Bu durumda bu bir sorun değil. Apache'yi manuel olarak yapılandırırsanız, yine de bir sorundur. ONE_PROCESSBölüm bunu tek işlem yerleşik modda çalışır durumda ayıklama modunda, içine zorlamak zaman içindir. Yine de ana tercümanda çalışıyor.

— Graham Dumpleton

Üzerindeki application-groupseçenek, WSGIScriptAliaskullanıma alternatiftir WSGIApplicationGroup.

— Graham Dumpleton

3

WSGI'yı yapılandırma yöntemime uyan başka bir çözüm de WSGIScriptAliashattı değiştirmekti :

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>

nitelikleri not et

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

bunlar genellikle gerekli değildir

— Nils Werner
kaynak

1

WSGIScriptReloading yönergesini varsayılan olarak açık olduğu ve genellikle kapatılması gerekmediği için bırakabilirsiniz. WSGIScriptAlias için işlem grubu seçeneğini kullandığından, WSGIProcessGroup yönergesini de bırakabilirsiniz.

— Graham Dumpleton

Scipy yüklendikten sonra yanıt vermeyen apache + mod_wsgi