2012-05-11 11 views
8

Dies fing an, unseren Arsch auf unserem Produktionsserver wirklich hart zu beißen. Wir haben das gelegentlich gesehen (für 1 Anfrage pro Woche). Damals haben wir herausgefunden, dass mod_wsgi in einigen Konfigurationen funky ist. Da wir den Grund für den Fehler nicht finden konnten, entschieden wir uns, dass es keine sofortige Aufmerksamkeit erforderte.mod_wsgi error - class .__ dict__ im eingeschränkten Modus nicht erreichbar

Heute jedoch, auf einem unserer Produktionsserver, ist dies wirklich bei 10% aller Serveranfragen aufgetreten; dh 10% aller Server-Anforderungen mit diesem selben Fehler fehlgeschlagen:

mod_wsgi (pid=1718): Target WSGI script '/installation/dir/our-program/prod-dispatch.wsgi' cannot be loaded as Python module. 
mod_wsgi (pid=1718): Exception occurred processing WSGI script '/installation/dir/our-program/prod-dispatch.wsgi'. 
Traceback (most recent call last): 
    File "/installation/dir/our-program/prod-dispatch.wsgi", line 7, in <module> 
    from pyramid.paster import get_app 
    File "/installation/dir/venv/local/lib/python2.7/site-packages/pyramid-1.3a6-py2.7.egg/pyramid/paster.py", line 12, in <module> 
    from pyramid.scripting import prepare 
    File "/installation/dir/venv/local/lib/python2.7/site-packages/pyramid-1.3a6-py2.7.egg/pyramid/scripting.py", line 1, in <module> 
    from pyramid.config import global_registries 
    File "/installation/dir/venv/local/lib/python2.7/site-packages/pyramid-1.3a6-py2.7.egg/pyramid/config/__init__.py", line 61, in <module> 
    from pyramid.config.assets import AssetsConfiguratorMixin 
    File "/installation/dir/venv/local/lib/python2.7/site-packages/pyramid-1.3a6-py2.7.egg/pyramid/config/assets.py", line 83, in <module> 
    @implementer(IPackageOverrides) 
    File "/installation/dir/venv/local/lib/python2.7/site-packages/zope.interface-3.8.0-py2.7-linux-x86_64.egg/zope/interface/declarations.py", line 480, in __ 
    classImplements(ob, *self.interfaces) 
    File "/installation/dir/venv/local/lib/python2.7/site-packages/zope.interface-3.8.0-py2.7-linux-x86_64.egg/zope/interface/declarations.py", line 445, in cl 
    spec = implementedBy(cls) 
    File "/installation/dir/venv/local/lib/python2.7/site-packages/zope.interface-3.8.0-py2.7-linux-x86_64.egg/zope/interface/declarations.py", line 285, in im 
    spec = cls.__dict__.get('__implemented__') 
RuntimeError: class.__dict__ not accessible in restricted mode 

Ubuntu Präzise, ​​64-Bit, mit den neuesten Apache, mod_wsgi, Python 2.7, mit mpm_worker + mod_wsgi in Daemon Modus. Dies ist das einzige Programm, das auf dem Server läuft und es gibt nur einen WSgi-Interpreter in der Konfiguration. Liegt das daran, dass mpm_worker neue Threads erzeugt oder was? Noch wichtiger - wie können wir es beheben?

Wir haben die folgenden, um Anfragen auf 4 Daemon-Prozesse basierend auf einem Cookie zu unterteilen.

WSGIPythonOptimize 1 

WSGIDaemonProcess sticky01 processes=1 threads=16 display-name=%{GROUP} 
WSGIDaemonProcess sticky02 processes=1 threads=16 display-name=%{GROUP} 
WSGIDaemonProcess sticky03 processes=1 threads=16 display-name=%{GROUP} 
WSGIDaemonProcess sticky04 processes=1 threads=16 display-name=%{GROUP} 

<VirtualHost *:81> 
    ... 
    WSGIRestrictProcess sticky01 sticky02 sticky03 sticky04 
    WSGIProcessGroup %{ENV:PROCESS} 
    ... 

    WSGIScriptAlias//installation/dir/our-program/prod-dispatch.wsgi   
</VirtualHost> 

Antwort

9

Es ist seit langem bekannt, dass mehrere Subinterpreter nicht gut entlang C-Erweiterungen spielen. Was ich jedoch nicht bemerkt habe ist, dass die Standardeinstellungen sehr unglücklich sind. ModWSGI wiki eindeutig fest, dass der Standardwert für WSGIApplicationGroup Direktive% ist {RESOURCE}, um die Wirkung von denen sein soll, dass

The application group name will be set to the server hostname and port as for the %{SERVER} variable, to which the value of WSGI environment variable SCRIPT_NAME is appended separated by the file separator character.

Dies bedeutet, dass für jeden Host: je Header auf beim Zugriff auf den Server der mod_wsgi freundlich ein neues subinterpreter laicht , für die die C-Erweiterungen dann geladen werden.

Ich hatte unwissentlich den Fehler durch den Zugriff auf localhost.invalid: 81 mit Links Browser auf diesem lokalen Server ausgelöst verursacht 1 unserer 4 WSGIDaemonProcesses für alle zukünftigen eingehenden Anfragen fehlschlagen.

Summa summarum: Wenn Sie mod_wsgi mit Pyramiden oder einem anderen Framework verwenden, das C-Erweiterungen verwendet, stellen Sie sicher, dass WSGIApplicationGroup immer auf% {GLOBAL} gesetzt ist. Mit anderen Worten, das Ergebnis der Verwendung der Standardeinstellungen wird dazu führen, dass Sie sich in den Fuß schießen, nach dem Sie sich vielleicht auch in den Kopf schießen wollen.

+3

Es gibt nicht alle C-Erweiterungen, die Probleme haben, nur bestimmte. Manchmal liegt das an einer fehlerhaften Codierung in den C-Erweiterungen. In anderen Fällen besteht das Problem darin, dass sie eine vereinfachte API zum Behandeln von Thread-Zuständen in Python verwenden. Obwohl es eine gute Faustregel ist, eine Daemon-Prozessgruppe zu verwenden und die Verwendung des Haupt-Interpreters zu erzwingen, ist dies nicht immer notwendig. –

+0

OK, danke für die Klarstellung. Ich denke jedoch immer noch, dass der Standardwert von% {RESOURCE} unglücklich ist, da er zwei Subinterpreter für dasselbe wsgi-Skript auf demselben virtuellen Host erstellt, auch wenn er mit http://127.0.0.1 und http: // localhost darauf zugreift. Es ist zu magisch. –

+1

% {RESOURCE} sollte den Wert von ServerName aus dem VirtualHost verwenden, mit dem es übereinstimmte. Wenn dies nicht der Fall ist, gibt es ein Problem mit der Apache-Konfiguration. –

Verwandte Themen