8

これにより、本番サーバーでお尻を激しく噛み始めました。これは時々見られました（週に1回のリクエスト）。当時、mod_wsgiがいくつかの設定でファンキーなことをしていることが原因であることがわかりました。バグの原因を突き止めることができなかったため、すぐに注意を払う必要はないと判断しました。

ただし、今日、本番サーバーの1つで、これはすべてのサーバー要求の10％で実際に発生しました。つまり、すべてのサーバー要求の10％が、これとまったく同じエラーで失敗しました。

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 Precise、64ビット、最新のApache、mod_wsgi、Python 2.7、デーモンモードでmpm_worker+mod_wsgiを使用。これはサーバー上で実行されている唯一のプログラムであり、構成にはwsgiインタープリターが1つだけあります。これは、mpm_workerが新しいスレッドを生成するためですか、それとも何ですか？さらに重要なのは、どのように修正するかです。

Cookieに基づいて4つのデーモンプロセスへのリクエストを細分化するために、次のものがあります。

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>
4

1 に答える 1

10

複数のサブインタープリターがC拡張機能に沿ってうまく機能しないことは古くから知られています。しかし、私が気付いていなかったのは、デフォルト設定が非常に残念なことです。ModWSGI wikiは、WSGIApplicationGroupディレクティブのデフォルト値は％{RESOURCE}であると明確に述べており、その効果は次のようになります。

アプリケーショングループ名は、％{SERVER}変数の場合と同様に、サーバーのホスト名とポートに設定されます。この変数には、WSGI環境変数SCRIPT_NAMEの値がファイル区切り文字で区切られて追加されます。

これは、サーバーへのアクセス中に検出されたHost：ヘッダーごとに、mod_wsgiが新しいサブインタープリターを生成し、そのサブインタープリターにC拡張機能が読み込まれることを意味します。

このローカルサーバーのリンクブラウザでlocalhost.invalid：81にアクセスすると、無意識のうちにエラーが発生し、4つのWSGIDaemonProcessesの1つが今後のすべての着信要求で失敗しました。

Summa summarum：ピラミッドまたはC拡張機能を使用するその他のフレームワークでmod_wsgiを使用する場合は、常にWSGIApplicationGroupが常に％{GLOBAL}に設定されていることを確認してください。つまり、デフォルト設定を使用した結果、足で自分を撃ち、その後、頭でも自分を撃ちたいと思うかもしれません。

于 2012-05-11T20:42:02.557 に答える