<p>django-1.7.1とgeventで問題を引き起こすgunicorn19.x</p>

最初の質問です。プリロードオプションを削除することは役に立ちますか？
別の同様の問題が報告されたことを覚えていると思います。
そのオプションを変更することが役立つ場合は、Djangoアプリケーションのロード方法について何かを変更している必要があり、追跡が容易になります。

マスタープロセスでdjangowsgiアプリケーションをインポートすると、少なくともdjango 1.7では、インポート時にすべてのdjangoモデルが初期化されると思います。

こんにちは@tilgovi 、お時間をいただきありがとうございます。 preload_app = Falseを使用すると、 gunicorn-19.1.1とdjango-1.7.1を使用できることを確認できpreload_app = Falseん。

バージョン19.x 、gunicornクラウドがこれについてどのように異なっているかについて何か考えがありますか？

私は今、2番目の問題を抱えています。 djangoアプリでRaven [1]を使用しています。 また、Ravenのドキュメントによると、WSGUミドルウェア[1]を使用する場合、RavenをWSGIオブジェクトとして使用する（元のdjango WSGIアプリをラップする）場合と、gunicornを使用する場合（ run_gunicornではなく外部コマンドとして使用する）が可能です。 preload_app = True場合にのみ起動しますが、geventは機能しません。 フックを有効にしてpreload_app = Trueを使用すると、gunicornが起動せず、 ImportErrorに「DJANGO_SETTINGS_MODULE」をインポートできないと表示されます。

レイヴンは4.2.3

今のところ、gunicorn 18.xに戻ります。これは、両方の構成（WSGIミドルウェアとしてのgeventとraven）で機能するためです。
これについて別の問題を開く必要がありますか？

[1] http://raven.readthedocs.org/en/latest/config/django.html#wsgi -middleware
[2] http://raven.readthedocs.org/en/latest/config/django.html#gunicorn

@daltonmatos django 1.7.1でデータベースをセットアップする方法が変更された可能性があり、スレッドセーフではないようです。 その時点でどうしたらよいかわかりません。

もう1つ、今日わかったばかりですが、
gunicorn19.3.0を使用したdjango1.7でのセッション処理は、数秒で期限切れになります。

それを機能させるには、18に戻す必要がありました。

ご参考までに。

これはhttps://github.com/benoitc/gunicorn/issues/879と同じ問題のようです

@tilgoviそれは環境で行われた変更によるものではないかと思います。 19.xではwsgi.multithreadをtrueに設定しましたが、18.xではfalseた。

https://github.com/benoitc/gunicorn/blob/master/gunicorn/workers/ggevent.py#L99

この変更は、djangoでは異なる方法で処理される場合があります。 そして、グリーンレットは実際にはスレッドではありません。 考え？ 少なくとも、元に戻して問題が解決するかどうかを確認することはできます。 この問題のテストまたは再現可能な方法はありますか？

ああ、それが問題だと思います。 良い思い出、@ benoitc。

理由はまだわかりません。 変更を正当化するためにその時に言ったように、それはフレームワークがデータの共有に関してより多くの予防策を講じるだけであることを意味するので、それが何かを壊すとは想像できません。 明らかに、私は間違っているかもしれません。

ブランチfix/927をプッシュして、上記の修正が機能するかどうかを確認しました。 テストしてください！

django 1.8.1（および1.7.1）とgevent1.0.1でfix / 927を使用しても、このエラーを再現できます。

原因がわからなくても、安心です。

そのため、サンプルアプリケーションを使用してみましたが、次のコマンドラインを実行しても問題は再現されませんでした。

gunicorn --env DJANGO_SETTINGS_MODULE=testing.settings -k gevent -w3 wsgi:application

再現可能な例を誰かに教えてもらえますか？

私はまだこの問題を次のようにgunicornを呼び出して再現することができます：

    gunicorn --env DJANGO_SETTINGS_MODULE=settings -w 3 --max-requests=1000 -b 0.0.0.0:8000 -k gevent --config ogs/gunicorn.py  --pythonpath ogs wsgi:application

必要な関連情報はありますか？

@brockhaywoodはproject.settingsである必要がありますが、はい、それを再現する方法が必要です。共有する最小限のコードはありますか。

上記のトレースを見ると、モンキーパッチの可能性もあります。 たぶん、スレッドにモンキーパッチを適用するべきではありません。 次のパッチを試すことができますか？

--- a/gunicorn/workers/ggevent.py
+++ b/gunicorn/workers/ggevent.py
@@ -60,9 +60,9 @@ class GeventWorker(AsyncWorker):

         # if the new version is used make sure to patch subprocess
         if gevent.version_info[0] == 0:
-            monkey.patch_all()
+            monkey.patch_all(thread=False)
         else:
-            monkey.patch_all(subprocess=True)
+            monkey.patch_all(subprocess=True, thread=False)

         # monkey patch sendfile to make it none blocking
         patch_sendfile()

上記のパッチを次のwsgiで使用しても、指定されたエラーは発生しなくなりました。

import os

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

from gevent import monkey
monkey.patch_all(thread=False)

from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()

from django.core.cache.backends.memcached import BaseMemcachedCache
BaseMemcachedCache.close = lambda self, **kwargs: None

私は今、別の新しいエラーを見ていますが、それが関連しているかどうかわかりません：

ProgrammingError: close cannot be used while an asynchronous query is underway

これは発生しており、10/15リクエストに1つがモデルでカウントを行っています。 これは私のアプリケーションのエラーであると思われますが、現在は明らかになっています。

@brockhaywoodかっこいい！ ところで、それはあなたのバージョンのgeventですか？ あなたの最新のエラーについては、それは確かにgunicornに関連していないようです。

ええ、良いニュースです！ geventのバージョン1.0.1。

@tilgoviなので、スレッドモンキーパッチを削除してgunicornにパッチを適用するべきではないかと思います。 たぶん、 wsgi.multithreadをFalse設定する必要がありますか？ 考え？

@benoitc上記で参照した新しいエラーを、ビューが1つだけで、単純なモデルクエリを実行し、複数の同時リクエストを実行した場合にカウントする非常に単純なDjangoアプリケーションで再現できます。

どのコンポーネントが原因である可能性が最も高いかについて、何か提案はありますか？ これはおそらくgeventの問題ですか、それともpsycogreenですか？

おそらくサイコグリーン。 そのようなフックを使用してセットアップしていますか？

def def_post_fork(server, worker):
    from psycogreen.gevent import psyco_gevent
    psyco_gevent.make_psycopg_green()
    worker.log.info("Made Psycopg Green")

ああ、私は実際に使用しています

def post_fork(server, worker):    
    from psycogreen.gevent import patch_psycopg
    patch_psycopg()

私はあなたの提案を試してみます。

psycogreenのコードを読んだ方が、あなたのコードはより正確です。

https://bitbucket.org/dvarrazzo/psycogreen/src/115d0627da1ac9ff48c0cb9287257cd35868cdf9/psycogreen/gevent.py?at=master#cl -17

はい、psycogreenでチケットを開いてみます

あなたはフックを使用しようとすることができますpost_worker_initの代わりにpost_fork ？

post_worker_initでpsycogreenにパッチを適用すると、まだ発生します。

psycogreenにもチケットを提出しました：
https://bitbucket.org/dvarrazzo/psycogreen/issue/2/databaseerror-used-with-asynchronous-query

@brockhaywood OK：/このリンクも見つかりました： https ： //bitbucket.org/dvarrazzo/psycogreen-hg/issue/1/databaseerror-execute-used-with 。 それがあなたを助けることができるかどうかはわかりませんが。

私はそれを調べました、そしてそれは同じ問題のように見えます、しかし私は残念ながら解決策を見ませんでした。

@brockhaywood問題の再現に役立つコードの簡単な例を教えてください。 明日見ていきます。

これが私が再現するために使用している単純なプロジェクトです：
https://github.com/brockhaywood/gunicorn_gevent_issue

ありがとう！

日、10：34 PMで2015年5月17日にはbrockhaywood [email protected]
書きました：

これが私が再現するために使用している単純なプロジェクトです：
https://github.com/brockhaywood/gunicorn_gevent_issue

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/benoitc/gunicorn/issues/927#issuecomment-102852497 。

@benoitcこれについて何か考えはありますか？

@brockhaywood申し訳ありませんが、テストする時間がありませんでした。 明日は飛行機に閉じ込められているので、とにかく:)

ありがとう
2015年5月26日午後1時17分、「BenoitChesneau」 [email protected]は次のように書いています。

@brockhaywood https://github.com/brockhaywood申し訳ありませんが、時間がありませんでした
それをテストします。 明日は飛行機に閉じ込められているので、とにかく:)

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/benoitc/gunicorn/issues/927#issuecomment-105652947 。

このスレッドを見たとき、同じDatabaseWrapperの問題が発生していました。

gunicornの設定ファイルからpreload_appオプションを削除すると、問題が解決することを確認できます。 私が使用しているもの：

• Django == 1.7.7
• gevent == 1.0.2
• gunicorn == 19.3.0
• psycopg2 == 2.5.2
• psycogreen == 1.0
• PgBouncerに包まれたgunicorn

（このスレッドで説明されているのと同じ問題が発生しているので、ジャンプします）

これらの問題は、問題＃478の修正が原因である

マスターにモンキーパッチを適用しないことにより、geventワーカーを使用している場合、アプリのプリロードは基本的に不一致を作成します。 プリロードの一部として実行されるアプリコードは、モンキーパッチが適用されていない環境で実行されます。 ワーカーで実行されるアプリコードはすべて、モンキーパッチが適用された環境で実行されます。

私たちにとっては、18.xで定義されているようにsetupメソッドをgeventワーカークラスに復元するだけで、マスターにモンキーパッチが適用され、アプリのプリロードの前にモンキーパッチが適用されます。すべて修正されました。私たちの問題。 これには、 DatabaseWrapperバグと、geventワーカーがハングしてタイムアウトする場所で見られた別の問題が含まれます。 他の変更は必要ありませんでした（たとえば、モンキーパッチthreadsを無効にする必要はありません）。

私はまだマスタープロセスにモンキーパッチを適用することを非常に躊躇しますが、それを実行したい場合は、gunicorn自体にパッチを適用する代わりにサーバーフックを使用できる可能性があります。 それができれば、ここよりも良い場所でそれを文書化できる方法を歓迎します。

私たちの短期的な計画は、このパッチを適用して（内部の）gunicornフォークを作成することだと思います。

モンキーパッチのステップをwsgiコードに移動することを調査しますが、これはgunicornコード内で実行する必要があるようです（構成可能なオプションとしても）。 プリロードされたアプリコードにパッチを適用すると、マスターに何らかの影響があります。重要なのは、ワーカーのモンキーパッチを適用した状態をマスターと同期させることです。 アプリコードにマスターモンキーパッチを適用するということは、この動作に依存するアプリ開発者は、モンキーパッチがいつ/どのようにワーカーにパッチを適用するかについてgunicornが行った変更に常に追いつくことを意味します。

早期にパッチを適用するように機能する場合は、変更と見なす必要があります。

それが事実だったのか、それが問題を引き起こしたのかは思い出せませんが、モンキーパッチでは常に注意が必要です。

独自の本番gunicornアプリケーションにはプリロード必要です（Pyramid / pasteのpserveスクリプトを使用してアプリを起動し、iniファイルからgunicornをロードします。その周りにラッパーがあります。モンキーパッチができるだけ早く発生することを確認してください）。

私は現在のgeventメンテナーです。 このシナリオをより適切に機能させるために必要なgeventの問題を確認できてうれしいです。 すぐに1.1を落とすと予想しており、これがサポートされているオプションであるとよいでしょう。

wsgi実装の上部に同じモンキーパッチロジックを適用しようとしましたが、 DatabaseWrapper問題が発生し始めました。 理由は完全にはわかりませんが、arbiter.pyのwsgi呼び出しを見ると、 GeventWorker.setupが呼び出されるポイントの数行後に発生します（ worker_class割り当ての副作用として。正しいコード。

ユーレカを持っているか、アプリコードに関して運が良ければフォローアップしますが、これまでのところ、gunicornマスターコードの早い段階でパッチを適用することが、すべての問題を解決する唯一の修正です。

@jamaddenどうもありがとう。

@jzupko通常、影響を受ける可能性のあるインポートの前にパッチを適用することが重要です。 そのため、 gunicorn.conf.pyファイルにpost_fork関数を配置するなど、サーバーフックで実行することを提案しました。 ただし、アプリケーションのプリロードはサーバーがフックする前に行われることに気づきました。どこでそれを行うかは明確ではありません。

@benoitcワーカー固有の構成のためのメカニズムはありますか？

これをリリース20のマイルストーンに追加し、＃478のような問題を再導入せずに実行できる場合は、マスターにモンキーパッチを適用することを検討することをお勧めします。

@tilgoviあなたは私が思うに使用できるワーカーのsetupメソッドを持っています。

20.0が出るまで、誰かがこれを一時的に修正していますか？ または、 preload_app無効にするか、18.0にダウングレードするかを選択する唯一の解決策ですか？

@fletomの一時的な修正？ 最新のマスターを試しましたか？ それはあなたのために働きましたか？

@benoitc 「DatabaseWrapperobjects」エラーの修正を意味します。

現在のgunicornマスターは実際にはまったく機能しません。 通常の19.6.0で、私はこれを取得します（通常）：

[2017-01-05 15:46:32 -0500] [3222] [INFO] Starting gunicorn 19.6.0
[2017-01-05 15:46:32 -0500] [3222] [INFO] Listening at: http://127.0.0.1:8000 (3222)
[2017-01-05 15:46:32 -0500] [3222] [INFO] Using worker: gevent
[2017-01-05 15:46:32 -0500] [3226] [INFO] Booting worker with pid: 3226
[2017-01-05 15:46:32 -0500] [3227] [INFO] Booting worker with pid: 3227
[2017-01-05 15:46:32 -0500] [3228] [INFO] Booting worker with pid: 3228
[2017-01-05 15:46:32 -0500] [3229] [INFO] Booting worker with pid: 3229

そして、100％まったく同じ構成の最新のマスターでは、これを取得し、私が知る限り、どのポートでも何もリッスンしていません。

[2017-01-05 15:47:19 -0500] [3308] [INFO] Starting gunicorn 19.6.0
[2017-01-05 15:47:19 -0500] [3308] [INFO] Listening at:  (3308)
[2017-01-05 15:47:19 -0500] [3308] [INFO] Using worker: gevent
[2017-01-05 15:47:19 -0500] [3312] [INFO] Booting worker with pid: 3312
[2017-01-05 15:47:19 -0500] [3313] [INFO] Booting worker with pid: 3313
[2017-01-05 15:47:19 -0500] [3314] [INFO] Booting worker with pid: 3314
[2017-01-05 15:47:19 -0500] [3315] [INFO] Booting worker with pid: 3315

バグがあるようですか？

@fletomどうやってgunicornを起動しますか？

@benoitcこの場合、 gunicorn -c gunicorn_conf.py <appname>.wsgiです。

私のgunicorn_conf.pyは次のとおりです。

workers = 4

worker_class = 'gevent'

preload_app = False

私はgunicorn==18.0この問題に遭遇しています。 gunicorn_conf.pyには、 worker_class = 'gevent' 、 preload_app = True 、カスタムpre_fork 、 on_starting 、 on_reload関数があります。

これらの行をgunicorn_conf.pyファイルの上に置くと、問題が解決するようです。

import gevent.monkey
gevent.monkey.patch_thread()

アップデート：
gunicorn.confにこれらの行があります。 それらを取り除くことは、モンキーパッチなしで問題を解決しました。

import django
django.setup()

それらのために、djangoはgunicornのモンキーパッチの前に接続を開始しました。

@gukoffが提案した修正は私には機能しませんでしたが、それでも同じエラーが発生します😞

これを閉じて、geventでアービターにモンキーパッチを適用するためのR20マイルストーンのメーリングリストラベルとのディスカッションを開きます。 このディスカッションで何かに関連する問題があり、それがGunicornのバグである可能性があると思われる場合は、問題を開いてください。 コンテキストを追加するのに役立つ場合は、これを番号で言及するか、コメントへのリンクを付けることができますが、現時点では、これはGunicornのいくつかのバージョンとさまざまな症状について並行して会話する古いチケットです。