<p>セロリ発生エラー：[Errno104]開始後にピアによって接続がリセットされました</p>

Celery4.2.0でも同じ問題が発生します。 セロリ4.1.1では持っていません。 ローカルでは、常にではありませんが、Errno 104を入手することがよくあります。travisビルドでは、4.2.0でより一貫して失敗するようです（4.1.1で成功します）。 @axiaoxinが報告する時間依存性に気づいていません。

次のコマンドの出力を提供していただけますか？

$ celery -A proj report

こんにちは@georgepsarakisこれは私のレポートです

software -> celery:4.2.0 (windowlicker) kombu:4.2.1 py:2.7.5
            billiard:3.5.0.3 py-amqp:2.3.2
platform -> system:Linux arch:64bit, ELF imp:CPython
loader   -> celery.loaders.app.AppLoader
settings -> transport:amqp
results:sentinel://:**@10.18.7.1:26379/1;sentinel://:[email protected]:26379/1;sentinel://:[email protected]:26379/1

JSON_AS_ASCII: False
CACHED_OVER_EXEC_MILLISECONDS: 800
LOG_PEEWEE_SQL: False
SESSION_REFRESH_EACH_REQUEST: True
APP_ROOT_PATH: '/data/srv/zns/app'
REDIS_URL: 'redis://:[email protected]:6379/2'
PROJECT_ROOT_PATH: '/data/srv/zns'
FLATPAGES_ROOT: '/data/srv/zns/app/docs'
SESSION_COOKIE_SAMESITE: None
PROPAGATE_EXCEPTIONS: None
CELERYD_SEND_EVENTS: True
REDIS_LOCK_TIMEOUT: 1800
FAKE_HANDLE_TASK: False
SECRET_KEY: u'********'
BROKER_URL: u'amqp://notifer:********@zns.com:5672/notifer_celery_broker'
ENTRY_RATE_LIMIT: 0
SENTRY_DSN: 'http://6a0ce3f93804422da7321f45353c69d7:[email protected]/10'
SWAGGER: {
    'description': '<a href="/docs" target="_blank">\xe5\x85\xb6\xe4\xbb\x96\xe6\x96\x87\xe6\xa1\xa3</a>',
    'doc_expansion': 'list',
    'footer_text': u'\u6709\u4efb\u4f55\u7591\u95ee\u8bf7\u54a8\u8be2 ashinchen',
    'hide_top_bar': True,
    'specs': [{   'endpoint': 'apispec', 'route': '/apispec.json'}],
    'termsOfService': None,
    'title': 'zns API',
    'uiversion': 3,
    'version': '0.0.1'}
LOG_LEVEL: 'info'
APPLICATION_ROOT: '/'
SERVER_NAME: None
LOG_PATH: '/data/srv/zns/logs'
SERVICE_NAME: 'zns'
CELERYD_MAX_TASKS_PER_CHILD: 10000
TESTING: False
MYSQL_URL: 'mysql+pool://user:[email protected]:3306/zns?max_connections=40&stale_timeout=300'
TEMPLATES_AUTO_RELOAD: None
CELERY_RESULT_PERSISTENT: True
JSONIFY_MIMETYPE: 'application/json'
TOF_APP_KEY: u'********'
TOF_SYS_ID: 1
JSON_KEYCASE: u'********'
TOF_URL: 'http://tof.com/api/v1'
FLATPAGES_EXTENSION: ['.md', '.html', '.htm', '.txt']
SESSION_COOKIE_HTTPONLY: True
USE_X_SENDFILE: False
REQUESTS_POOL_SIZE: 10
API_BIND: u'********'
SESSION_COOKIE_SECURE: False
CACHED_EXPIRE_SECONDS: 60
REDIS_SENTINEL: {
    'db': 0,
    'master_name': 'redis-master',
    'nodes': [   ('10.18.7.1', 26379),
                 ('10.16.19.22', 26379),
                 ('10.16.19.21', 26379)],
    'password': u'********'}
SESSION_COOKIE_DOMAIN: None
SESSION_COOKIE_NAME: 'session'
EXCEPTION_RETRY_COUNT: 2
CELERY_TASK_RESULT_EXPIRES: 604800
MAX_COOKIE_SIZE: 4093
ENTRY_RATE_PER: 0
TOF_WEIXIN_SENDER: 'x-ashin'
ENV: 'production'
CELERYD_TASK_SOFT_TIME_LIMIT: 30
DEBUG: False
PREFERRED_URL_SCHEME: 'http'
EXPLAIN_TEMPLATE_LOADING: False
CELERY_RESULT_BACKEND:u'sentinel://:********@10.18.7.1:26379/1;sentinel://:pwd@'10.16.19.22:26379/1;sentinel://:[email protected]:26379/1'
CACHED_CALL: False
FLATPAGES_AUTO_RELOAD: False
MAX_CONTENT_LENGTH: None
REQUEST_ID_KEY: u'********'
NOTIFY_MODULE: 'tof'
JSONIFY_PRETTYPRINT_REGULAR: False
LOG_FUNC_CALL: True
PERMANENT_SESSION_LIFETIME: datetime.timedelta(31)
TOF_EMAIL_SENDER: '[email protected]'
REDIS_CLUSTER: {
    }
TRAP_BAD_REQUEST_ERRORS: None
JSON_SORT_KEYS: u'********'
TRAP_HTTP_EXCEPTIONS: False
SESSION_COOKIE_PATH: None
SEND_FILE_MAX_AGE_DEFAULT: datetime.timedelta(0, 43200)
SPLIT_LOGFILE_BY_LEVEL: False
PRESERVE_CONTEXT_ON_EXCEPTION: None
CELERY_RESULT_BACKEND_TRANSPORT_OPTIONS: {
    'master_name': 'redis-master'}
LOG_IN_FILE: False

このレポートのように、一部のパスワードは*に置き換えられません。

その価値については、rabbitmqでgeventを使用したクリーンなプロジェクトでもこれを確認しています。 セロリワーカーを数分間起動すると、接続がリセットされ、それ以降はタスクが消費されなくなります。

https://github.com/sihrc/celery-connection-reset

これまでのところ同じ問題があります。（セロリ4.2）セロリのバージョンを4.1にダウングレードすることで解決しましたが、このエラーが発生した理由はわかりません。

マスターからのすべての依存関係とともにマスターブランチからセロリをインストールして、何が起こっているかを確認できますか？

Celery4.2.2でもこのエラーが発生します。

@auvipyありがとう、それは動作します！

@ yuda110依存関係にどのような変更を加えると問題が解決したか知っていますか？

このConnectionResetの問題が発生しており、Celery 4.2.1を使用しており、Celeryの要件と互換性のある次のバージョンが固定されています。

billiard==3.5.0.4 # Celery needs billiard. There's a bug in 3.5.0.5
kombu==4.2.2-post1 # Celery needs kombu >= 4.2.0, < 5.0
redis==2.10.6

@charlescapps
ああ、その答えを消すのを忘れた☹️☹️バージョンを（4.2.1に）アップグレードすると問題は解決したようですが、再び未知の問題に直面しました。 最終的にはバージョン4.0にダウングレードする必要がありました。

4.1にダウングレードすると、エラーが修正されました。 4.3はまだ試していません。

このエラーが発生することはめったにありません。これは、redisクライアントからのConnectionResetエラーで始まる連鎖例外であることがわかりました。 Celery ChangeLogはこれが再試行可能なエラーであることを示しているため、 kombu.exceptions.OperationalErrorがスローされたときに再試行を有効にするだけです。

RabbitMQを使用しても、4.3.0でも問題が解決しないことを伝えたかっただけです。 どういうわけかRedisに移行すると問題が修正されました。

kombu.exceptions.OperationalErrorがスローされるたびに指数バックオフで再試行することで、これを解決しました。 ドキュメントによると、これらは再試行することを目的としています。 この問題が発生することはめったにないため、再試行することをお勧めします。 私たちは4.2.1にいます。

こんにちは、

ブローカーとバックエンドとしてrabbitmqを使用していますが、同じ問題が発生しています。

誰かが解決策を持っていますか？

前もって感謝します。

ここで同じ問題。 これは私にとって100％再現可能です。 何らかの理由で、ブローカーへのソケットは、ハートビート間隔と思われる間隔の後に停止します。

報告書：

software -> celery:4.3.0 (rhubarb) kombu:4.5.0 py:3.6.7
            billiard:3.6.0.0 py-amqp:2.4.2
platform -> system:Linux arch:64bit, ELF
            kernel version:4.18.0-20-generic imp:CPython
loader   -> celery.loaders.app.AppLoader
settings -> transport:amqp results:rpc:///

broker_url: 'amqp://guest:********<strong i="7">@localhost</strong>:5672//'
result_backend: 'rpc:///'
result_persistent: False
task_default_queue: 'something something'
result_expires: 3600
task_ignore_result: False
task_serializer: 'json'
result_serializer: 'json'
accept_content: ['json']
timezone: 'Europe/Berlin'
enable_utc: True

私の問題はErlang22.0にアップグレードしたときに始まったと言わざるを得ません。 しかし、それは偶発的なことかもしれません。

修正を提案できますか？ 可能であれば、それは4.4.0rc2に含まれます

この動作は、4.3.0でもgeventworkerで確認できます。 geventからpreforkに切り替えると、問題が解決するようです。 4.1.1にダウングレードしようとしましたが、Python 3.7ではコンパイルすらできない古いバージョンのgevent（1.2.2）が必要なため、Python3.7では機能しないようです。 問題が発生すると、rabbitmqログに次のメッセージが表示されることに気付きました。

missed heartbeats from client, timeout: 60s

興味深いことに、ハートビートが失敗したにもかかわらず、ワーカーはタスクを取得して正常に処理します。 ワーカーが再起動されるまで、 celery inspectコマンドがすべてタイムアウトするだけです。 flower引き続きワーカーのダッシュボードに情報を表示しますが、ワーカー自体をクリックすると404 Not Foundエラーが発生し、花はセロリ検査コマンドに関連するエラーをログに記録します。

monitor_1    | 2019-08-27 17:39:05.483286 [warning  ] 404 GET /worker/celery<strong i="11">@38245f8fef62</strong> (172.20.0.1): Unknown worker 'celery<strong i="12">@38245f8fef62</strong>' [tornado.general] 
monitor_1    | 2019-08-27 17:39:24.608962 [warning  ] 'stats' inspect method failed [flower.api.control] 
monitor_1    | 2019-08-27 17:39:24.609429 [warning  ] 'active_queues' inspect method failed [flower.api.control] 
monitor_1    | 2019-08-27 17:39:24.609847 [warning  ] 'registered' inspect method failed [flower.api.control] 
monitor_1    | 2019-08-27 17:39:24.610221 [warning  ] 'scheduled' inspect method failed [flower.api.control] 
monitor_1    | 2019-08-27 17:39:24.610905 [warning  ] 'active' inspect method failed [flower.api.control] 
monitor_1    | 2019-08-27 17:39:24.611369 [warning  ] 'reserved' inspect method failed [flower.api.control] 
monitor_1    | 2019-08-27 17:39:24.611890 [warning  ] 'revoked' inspect method failed [flower.api.control] 
monitor_1    | 2019-08-27 17:39:24.612512 [warning  ] 'conf' inspect method failed [flower.api.control] 

セロリ4.4.0rc3 +昆布4.6.3でこれを確認する人が必要ですか？

しましょう。 参考までに、セロリ4.4.0rc3には昆布4.6.4が必要です。

celery 4.4.0rc3 has requirement kombu<5.0,>=4.6.4, but you'll have kombu 4.6.3 which is incompatible.

OK、4.4.0rc3はこの問題を解決しているようです。 geventワーカーを使用して、ハートビートエラーなしで5分以上そのままにしました。

昆布4.6.3も互換性があります

その場合は、セロリプロジェクトの要件ファイルを更新することをお勧めします。

しかし、私たちは何を変えましたか？

また、これが閉じられる原因となった変更点や、PR /コードなどへのリンクについての洞察も必要です。 影響を受けており、最適ではないハートビートを無効にすることで影響を軽減しています（prefork、rabbitmq、celery 4.3）。

@auvipy Ping？

OK、4.4.0rc3はこの問題を解決しているようです。 geventワーカーを使用して、ハートビートエラーなしで5分以上そのままにしました。

このフィードバックに基づいて問題は解決されました

@auvipy同様のエラーにつながる問題が複数あるようです。 問題を解決する前に、おそらくいくつかの古いバージョンのCeleryを使用して、バグをローカルで再現しようとすると便利です。

マスターブランチを試すことをお勧めします。

以前のバージョン（4.1、4.2、4.3など）の1つでバグを再現し、4.4にアップグレードするだけで問題が解決することを確認することをお勧めします。 一人のフィードバックに基づいて、あなた自身の検証なしにバグを閉じるのは少し急いでいるようです。

あなたは問題に直面しているので、あなたが提案したように最初に確認する必要があります。 @czyzby

あなたが提案したようにあなたが最初に確認する必要があります

_ "should"？_;）プロジェクトの品質を_should_気にする人がいるなら、それは公式のメンテナです。 ソフトウェアを無料で提供していただきありがとうございますが、すべてのユーザーがプロジェクトに貢献することを現実的に期待することはできません。

とにかく、問題の原因となった構成はもうありませんが、タスクが定義されていない空のキューの場合でも問題が続くと思うので、再現しやすいかもしれません。 その後、Redisに移行することで問題を解決しました。これは、当時のチームがテクノロジーを簡単に変更できるためです。 そして、完全に正直に言うと、Celeryの他の問題のためにRQへの移行を検討しています。

4.4.0rc4もこの問題を解決しているようですが、

それをチェックできる他の人はcelery == 4.4.0rc4で修正されます

@auvipy私は4.3.0で、たまにConnection reset 。 私にとって4.4.0rc4の問題はもうありません。

それをチェックできる他の人はcelery == 4.4.0rc4で修正されます

4.3.0で問題が発生する頻度は非常に高く、4.4.0rc4では問題の発生頻度ははるかに低くなりますが、それでも時々発生します。
私はredis-server5.0.6とpythonredis Client 3.3.11を最大14の定期的なタスク（30秒ごと）で使用しています。
だから私はあなたに問題を再開するようにお願いします。
ありがとう！

4.3.0で問題が発生する頻度は非常に高く、4.4.0rc4では問題の発生頻度ははるかに低くなりますが、それでも時々発生します。
私はredis-server5.0.6とpythonredis Client 3.3.11を最大14の定期的なタスク（30秒ごと）で使用しています。
だから私はあなたに問題を再開するようにお願いします。
ありがとう

実際、この問題はデフォルト設定でも発生します。 ただし、他のスレッドで説明されているように、 celeryconfig.py broker_heartbeat = 0を設定すると役立つようです。

celery 4.4.0rc4にアップグレードし、celery.pyにCELERY_BROKER_HEARTBEAT = 0を追加した後でも、私にとっては何も変わらないようで、エラーが発生します。

セロリ4.2.0から4.10にダウングレードした後も問題は解決しませんでした

次のバージョンは、私たちのプロジェクトではusinfです。
ビリヤード== 3.5.0.2、昆布== 4.1.0、セロリ== 4.1.0、amqp == 2.4.2

提案してください

私たちはこれ、またはこの問題に非常によく似た何かを見始めました。

ソフトウェア->セロリ：4.3.0 （ルバーブ）昆布：4.5.0py：2.7.12
ビリヤード：3.6.0.0redis ：3.2.1

それは1日に数回発生し始めましたが、実際の変化はありませんでした。
次のリリースでは、最新バージョンのcelery 4.4.0、redisなどへのアップグレードを試みて報告します。

（concurrency = 1000（gevent）＆redis asbroker）で私に起こります：
セロリ== 4.4.0（崖）
昆布== 4.6.7
ビリヤード== 3.6.2.0
（py-）redis == 3.4.1

Redisサーバーバージョン= 5.0.7
Python 3.7.3

https://sentry.io/share/issue/85f87e60a7c441198c082b9ebf051693/

• 7つのタスクが10秒ごとに実行されるように設定されています。
• エラーはセロリビートでのみ発生し、1時間に3件未満でエラーが発生することはめったにありません。

タグ

• ロガー：celery.beat
• ランタイム：CPython 3.7.5

環境

• Linux-4.15.0-1060-aws-x86_64-with-Ubuntu-18.04-bionic
• Python 3.7.5（デフォルト、2019年11月7日、10：50：52）[GCC 8.3.0]
• Redisサーバーv = 4.0.9 sha = 00000000：0 malloc = jemalloc-3.6.0ビット= 64ビルド= 9435c3c2879311f3
• セロリ== 4.4.0
• ビリヤード== 3.6.1.0
• 昆布== 4.6.7
• redis == 3.3.11

これは、asyncioのopen_connectionを使用してTCPサーバーに接続するときに発生します。 VPN内のリモートサーバーに接続してから15分後に、切断されます。 これは接続がアイドル状態であるためだと思います。 リモートサーバー内から接続している場合、同じことは起こりません。 これはネットワークに関連しているようです。

私は自分の事件を解決しました！ Uff。

セロリの問題ではありませんでした。 4. [234] .0を含むいくつかのバージョンを試しました。また、RedisへのPythonインターフェイスのいくつかのバージョンを試しました。 そして、私はいつも同じ失敗率を持っていました（50万のリクエストに対して約2‰）

解決策は、redisサーバーの再構成、つまりすべてのクラスのclient-output-buffer-limitを無効にすることでした。 redisのドキュメントによると：

ハード制限に達すると、またはソフト制限に達して指定された秒数の間（継続的に）到達したままになると、クライアントはすぐに切断されます。
…
ハード制限とソフト制限の両方をゼロに設定することで無効にできます。

皆様のお役に立てば幸いです。 または多分あなたは私の解決策を改善するでしょう。

私は自分の事件を解決しました！ Uff。

セロリの問題ではありませんでした。 4. [234] .0を含むいくつかのバージョンを試しました。また、RedisへのPythonインターフェイスのいくつかのバージョンを試しました。 そして、私はいつも同じ失敗率を持っていました（50万のリクエストに対して約2‰）

解決策は、redisサーバーの再構成、つまりすべてのクラスのclient-output-buffer-limitを無効にすることでした。 redisのドキュメントによると：

ハード制限に達すると、またはソフト制限に達して指定された秒数の間（継続的に）到達したままになると、クライアントはすぐに切断されます。
…
ハード制限とソフト制限の両方をゼロに設定することで無効にできます。

皆様のお役に立てば幸いです。 または多分あなたは私の解決策を改善するでしょう。

これは私にとってもうまくいきましたが、他の提案はどれもうまくいきませんでした。 ありがとうございました！

セットアップの問題が解決したことも確認できます。 この@rganowskiに時間を割いていただきありがとうございます！

これで問題が解決した場合は素晴らしいですが、構成ファイルからデフォルトを削除する前に、その設定が何をするのか、なぜそれがデフォルト構成の一部であるのかを知っておくとよいと思います。

@Moulde構成ファイルからデフォルトを削除することについて話しているとはどういう意味かよく

また、なぜそのようなデフォルトが存在するのか知りたいですか？ それは意識的でしたか？ もしそうなら、それらをあきらめるリスクは何ですか？ しかし、正直に言うと、私はそれをチェックするつもりはありません。 10MDのタスクがあり、3MDを無料で追加する必要がありました。

誰もそれが問題を解決するとは言いませんでした。 私は自分の場合の解決策を見つけたと言った。 他の2人の相棒はそれが彼らのためにも働くと言いました。 私はそれを喜んで読みました。 しかし、私がそのように読んだあなたの言葉：「それを証明する」。 私が間違っている？

アプリケーションでテストして、問題がないかどうかお知らせください。 他の疑問を解決する場合は、他の人と共有することを忘れないでください。

@rganowski同意しているようですが、そうです、私の言い回しであなたが何を意味しているのかわかります。それはそのような意味ではありませんでしたが、システムのデフォルトを変更する前に少し健全な懐疑論を追加し、おそらくドキュメントを少し批評します-ファイルにある「何をするのか」の部分のほかに、なぜその設定が必要なのかについてのちょっとした情報があれば素晴らしいでしょう:)
そして、あなたがこれに費やした時間のおかげで、私はそれを自分で理解しなかっただろう。

Celeryコードにエラーがなかったため、問題は解決されましたが、問題の背後にある問題は解決されていません。 redisバックエンド設定のドキュメントに適切な警告を追加する必要があると思います。

'client-output-buffer-limit'をグーグルで検索すると、多くの興味深い記事が見つかります。 1つは、すでに6歳で、結果として、非常に美しいタイトルであるThe ReplicationBuffer-Devopsの頭痛を回避する方法があります。 そこで私たちは読むことができます：

レプリケーションバッファのサイズを増やす前に、マシンに十分なメモリがあることを確認する必要があります。

他のいくつかの記事では、クライアントバッファ-本番環境でRedisを使用する前に、これを確認してください。 著者は言う：

デフォルトでは、通常のクライアント（通常の実行コマンド）は、（プッシュ方式で）要求せずにデータを受信しないため制限されていませんが、要求の直後であるため、非同期クライアントのみが、データが要求されるよりも速くデータが要求されるシナリオを作成できます。読んだ。

それは私たちの場合ではありませんか？

私にとって、少なくとも今までは、再構成は救いであることが判明しました。 非常に重くて瞬時の負荷で、新しい「104」エラーはありません。

@rganowski @Moulde @ CM2Walki

こんにちは、私は非常に素朴に聞こえるかもしれませんが、すべてのクラスのclient-output-buffer-limitを無効にするために必要な変更をどこで行うことができるか教えてください。 私も同じエラーが発生しているので、どういうわけか私はあなたの答えを解釈することができません。 それで、私が必要な変更を加えることができるように、あなたの答えを詳しく説明していただけませんか。 ありがとうございました！

Celeryコードにエラーがなかったため、問題は解決されましたが、問題の背後にある問題は解決されていません。 redisバックエンド設定のドキュメントに適切な警告を追加する必要があると思います。

'client-output-buffer-limit'をグーグルで検索すると、多くの興味深い記事が見つかります。 1つは、すでに6歳で、結果として、非常に美しいタイトルであるThe ReplicationBuffer-Devopsの頭痛を回避する方法があります。 そこで私たちは読むことができます：

レプリケーションバッファのサイズを増やす前に、マシンに十分なメモリがあることを確認する必要があります。

他のいくつかの記事では、クライアントバッファ-本番環境でRedisを使用する前に、これを確認してください。 著者は言う：

デフォルトでは、通常のクライアント（通常の実行コマンド）は、（プッシュ方式で）要求せずにデータを受信しないため制限されていませんが、要求の直後であるため、非同期クライアントのみが、データが要求されるよりも速くデータが要求されるシナリオを作成できます。読んだ。

それは私たちの場合ではありませんか？

私にとって、少なくとも今までは、再構成は救いであることが判明しました。 非常に重くて瞬時の負荷で、新しい「104」エラーはありません。

ドキュメントの改善PRに本当に感謝します

@ girijesh97 @auvipy

redis.confで

client-output-buffer-limit normal 0 0 0
client-output-buffer-limit replica 0 0 0
client-output-buffer-limit pubsub 0 0 0

@rganowski Sir繰り返しますが、私は非常に素朴に聞こえるかもしれませんが、セロリ（バージョン4.4.2）を使用していて、接続エラーの問題に直面しているDjangoアプリケーションがあります。 このredis.confファイルを見つけたり作成したりするのを手伝ってくれませんか。 このファイルをアプリケーションで作成する必要がありますか、それともいくつかのパッケージで利用できますか？

あなたのケースが同じである場合、私たちは話していました、あなたのセロリはredisサーバーの結果バックエンドを使用しています。 私が言及したファイルは、標準のredisサーバー構成ファイルです。 これが実際にはセロリの問題ではなく副作用である理由です。

@auvipy同じ問題のブローカーおよび結果バックエンドとしてのRabbitMQの修正はありますか。 長時間実行されるタスクでも4.4でこれを確認します。 上記の修正は、redisバックエンド専用です。

また、この問題はRabbitMQとcelery4.2.0で断続的に発生します。 パッケージのユーザーに強制するのではなく、再試行処理が組み込まれている場合でも。

私もそれを経験しています。 私はCelery4.3.0とRabbitMQ3.3.5を使用しています。