2017-10-09 8 views
0

こんにちは私はdjangoアプリを持っています。私のシステム全体の構成は次のとおりです:python 3、django 1.11、eventlet 0.21.0。イベントレットis_monkey_patchedの問題False

1)nginxの上流のサーバとして:

upstream proj_server { 
     server unix:///tmp/proj1.sock fail_timeout=0; 
     server unix:///tmp/proj2.sock fail_timeout=0; 
} 

2)従業員を制御スーパーバイザ。 gunicornワーカーがあります:

[program:proj] 
command=/home/vagrant/.virtualenvs/proj/bin/gunicorn -c /vagrant/proj/proj/proj/deploy/gunicorn.small.conf.py proj.wsgi:application 
directory=/vagrant/proj/proj/proj/deploy 
user=www-data 
autostart=true 
autorestart=true 
stdout_logfile=/var/log/supervisor/proj.log 

3)これは、gunicorn.small.confコンテンツです:

bind = ["unix:///tmp/proj1.sock", "unix:///tmp/proj2.sock"] 
pythonpath = "/vagrant/proj/proj/proj/deploy" 
workers = 2 
worker_class = "eventlet" 
worker_connections = 10 
timeout = 60 
graceful_timeout = 60 

4)そして、これはproj.wsgiコンテンツです:

""" 
WSGI config for proj project. 

This module contains the WSGI application used by Django's development server 
and any production WSGI deployments. It should expose a module-level variable 
named ``application``. Django's ``runserver`` and ``runfcgi`` commands discover 
this application via the ``WSGI_APPLICATION`` setting. 

Usually you will have the standard Django WSGI application here, but it also 
might make sense to replace the whole Django WSGI application with a custom one 
that later delegates to the Django one. For example, you could introduce WSGI 
middleware here, or combine a Django application with an application of another 
framework. 

""" 
import eventlet 
eventlet.monkey_patch() 
from eventlet import wsgi 
import django.core.handlers.wsgi 
import os 

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "proj.settings") 

# This application object is used by any WSGI server configured to use this 
# file. This includes Django's development server, if the WSGI_APPLICATION 
# setting points here. 
from django.core.wsgi import get_wsgi_application 
application = get_wsgi_application() 

# Apply WSGI middleware here. 
# from helloworld.wsgi import HelloWorldApplication 
# application = HelloWorldApplication(application) 

したがって、チェーンがあります:nginxはアップストリームサーバーとして2つのソケットを使用しているgunicornイベントレットワーカーの1つを呼び出しますproj1.sockまたはproj2.sock。 イベントレットのドキュメントに従って、できるだけ早くeventlet.monkey_patch()を使用しようとしています。そのための最も適切な場所は、まず最初にgunicornによって呼び出されるproj.wsgiです。

しかし、ライブラリはサルのパッチが当てられていないようです。これを確認するには

私はのproj/projの/ projの/ __ init__.py(Djangoアプリケーションによって呼び出された最初のモジュール)に次のコードを追加:私は間違って何をやっている

import eventlet 
import os 
print("monkey patched os is: " + str(eventlet.patcher.is_monkey_patched('os'))) 
print("monkey patched select is: " + str(eventlet.patcher.is_monkey_patched('select'))) 
print("monkey patched socket is: " + str(eventlet.patcher.is_monkey_patched('socket'))) 
print("monkey patched time is: " + str(eventlet.patcher.is_monkey_patched('time'))) 
print("monkey patched subprocess is: " + str(eventlet.patcher.is_monkey_patched('subprocess'))) 

then i issued **./manage.py check** and got that answer: 

monkey patched os is: false 
monkey patched select is: false 
monkey patched socket is: false 
monkey patched time is: false 
monkey patched subprocess is: false 

を?

答えて

1

proj.wsgiファイルの内容を1行に変更するとどうなりますかraise Exception?それは容疑者からイベントレットを取り除くはずです。

私はジャンゴで良いじゃないが、ここでは純粋な憶測です:WSGIサーバーが

  • manage.py checkを開始しようとしているとき

    • は名前に基づいて、proj.wsgiが実行された関連していないようです

      :リモート・ネットワーク・サービス(WSGI)に、それはWSGI関連のコード

    一つあなたの質問文から取られた可能性のある解決策を実行してはならないので、一般的な管理コマンドのようです

    がproj/projの/ projの/ のinitの.py(Djangoアプリケーション

    によって呼び出された最初のモジュールがそこにmonkey_patchコールを置くようにしてください。

    P.S.:gunicornの管理者は必要ありません。マスタープロセス(アービター)は、労働者の問題にもかかわらず永遠に実行されるように設計されています。

  • +0

    私は監督を使用しています。なぜなら、サーバー上の多くのプロセスは、ガンコンだけでなく管理する必要があるからです。 どのようなabou wsgi - 理にかなっています。私はあなたのアドバイス、おかげで試してみます。 –

    関連する問題