<p>셀러리 상승 오류 : [Errno 104] 시작 후 피어에서 연결 재설정</p>

Celery 4.2.0에서도 동일한 문제가 발생합니다. Celery 4.1.1에는 없습니다. 지역적으로, 항상 그런 것은 아니지만 자주 Errno 104를 얻습니다. 트래비스 빌드에서는 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로 다운 그레이드하여 해결되었지만이 오류가 발생한 이유를 모릅니다.

마스터의 모든 종속성과 함께 마스터 브랜치에서 셀러리를 설치하고 무슨 일이 일어나는지 볼 수 있습니까?

Celery 4.2.2에서 여전히이 오류가 발생합니다.

@auvipy 감사합니다, 작동합니다!

@ yuda110 의존성 변경으로 문제가 해결되었는지 알고 있습니까?

이 ConnectionReset 문제가 발생하며 셀러리 요구 사항과 호환되는 다음 버전이 고정 된 셀러리 4.2.1을 사용하고 있습니다.

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

안녕하세요.
아, 그 답을 지우는 걸 잊었 네요 ☹️☹️ 버전 업그레이드 (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

Erlang 22.0으로 업그레이드했을 때 문제가 시작되었다고 말해야합니다. 그러나 그것은 우연 일 수도 있습니다.

수정 사항을 제안 해 주시겠습니까? 가능하다면 4.4.0rc2에 포함될 것입니다.

4.3.0에서도 gevent 작업자를 사용하여이 동작을 확인할 수 있습니다. gevent에서 prefork로 전환하면 해결되는 것 같습니다. 4.1.1로 다운 그레이드를 시도했지만 Python 3.7에서 컴파일되지 않는 이전 버전의 gevent (1.2.2)가 필요하기 때문에 Python 3.7에서 작동하지 않는 것 같습니다. 문제가 시작되면 rabbitmq 로그에 다음 메시지가 표시됩니다.

missed heartbeats from client, timeout: 60s

흥미롭게도 하트 비트가 실패 했음에도 불구하고 작업자는 여전히 작업을 선택하고 잘 처리합니다. 작업자가 다시 시작될 때까지 celery inspect 명령이 모두 시간 초과됩니다. flower 여전히 작업자의 대시 보드에 정보를 표시하지만 작업자 자체를 클릭하면 404 Not Found 오류가 발생하고 꽃은 celery inspect 명령과 관련된 오류를 기록합니다.

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 + kombu 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.

좋습니다. 4.4.0rc3이이 문제를 해결하는 것으로 보입니다. gevent 작업자를 사용하여 하트 비트 오류없이 5 분 이상 그대로 두었습니다.

kombu 4.6.3도 호환됩니다.

이 경우 셀러리 프로젝트의 요구 사항 파일을 업데이트 할 수 있습니다.

그러나 우리는 무엇을 바꿨습니까?

나는 또한 이것이 닫히는 원인이 된 변경 사항에 대한 통찰력이나 PR / 코드 / 등에 대한 링크를 좋아합니다. 우리는 영향을 받았으며 차선책 인 하트 비트를 비활성화하여이를 완화합니다 (prefork, rabbitmq, celery 4.3).

@auvipy 핑?

좋습니다. 4.4.0rc3이이 문제를 해결하는 것으로 보입니다. gevent 작업자를 사용하여 하트 비트 오류없이 5 분 이상 그대로 두었습니다.

이 피드백에 따라 문제가 종결되었습니다.

@auvipy 유사한 오류로 이어지는 여러 문제가있는 것 같습니다. 문제를 해결하기 전에 일부 이전 Celery 버전을 사용하여 로컬에서 버그를 재현하려고 시도했다면 좋을 것입니다.

당신은 마스터 브랜치를 시도하는 것이 좋습니다.

이전 버전 (예 : 4.1, 4.2, 4.3) 중 하나로 버그를 재현하고 4.4로 업그레이드하는 것만으로 문제가 해결되었는지 확인하는 것이 좋습니다. 한 사람의 피드백을 기반으로 자신의 확인없이 버그를 닫는 것은 약간 성급하게 보입니다.

문제에 직면 했으므로 제안한대로 가장 먼저 확인해야합니다. 헉

제안한대로 가장 먼저 확인해야합니다.

_ "Should"? _;) 프로젝트의 품질에 관심을 _해야하는 _ 누군가가 있다면, 그것은 공식 관리자입니다. 소프트웨어를 무료로 제공하는 것에 감사하지만 모든 사용자가 프로젝트에 기여할 것이라고 현실적으로 기대할 수는 없습니다.

어쨌든 문제를 일으킨 구성은 더 이상 없지만 작업이 정의되지 않은 빈 대기열의 경우에도 문제가 지속되는 것 같아 재현하기 쉬울 수 있습니다. 우리 팀이 당시 기술을 쉽게 변경할 수 있었기 때문에 Redis로 마이그레이션하여 문제를 해결했습니다. 그리고 솔직히 말해서 Celery와 관련된 다른 문제로 인해 RQ 로의 이전을 고려하고 있습니다.

4.4.0rc4도이 문제를 해결하는 것으로 보입니다.

그것을 확인할 수있는 다른 사람은 celery == 4.4.0rc4로 수정되었습니다.

@auvipy 나는 가끔 Connection reset 와 함께 4.3.0에있었습니다. 4.4.0rc4에서 더 이상 문제가 없습니다.

그것을 확인할 수있는 다른 사람은 celery == 4.4.0rc4로 수정되었습니다.

4.3.0에서 문제가 자주 발생합니다. 4.4.0rc4에서는 문제가 훨씬 덜 발생하지만 때때로 여전히 발생합니다.
redis-server 5.0.6 및 python redis Client 3.3.11을 ~ 14 개의 주기적 작업 (30 초마다)과 함께 사용하고 있습니다.
그래서 나는 당신에게 문제를 다시 열 것을 요청합니다.
감사!

4.3.0에서 문제가 자주 발생합니다. 4.4.0rc4에서는 문제가 훨씬 덜 발생하지만 때때로 여전히 발생합니다.
redis-server 5.0.6 및 python redis Client 3.3.11을 ~ 14 개의 주기적 작업 (30 초마다)과 함께 사용하고 있습니다.
그래서 나는 당신에게 문제를 다시 열 것을 요청합니다.
감사

실제로이 문제는 기본 설정으로 여전히 발생합니다. 그러나 다른 스레드에서 언급했듯이 broker_heartbeat = 0 에서 celeryconfig.py broker_heartbeat = 0 를 설정하면 도움이되는 것 같습니다.

celery 4.4.0rc4 업그레이드하고 celery.py에 CELERY_BROKER_HEARTBEAT = 0 을 추가 한 후에도 별다른 변화가없는 것처럼 보이지만 여전히 오류가 발생합니다.

셀러리 4.2.0에서 4.10으로 다운 그레이드 한 후에도 문제가 해결되지 않았습니다.

Follwoing 버전은 우리 프로젝트에서 usinf입니다.
당구 == 3.5.0.2, 다시마 == 4.1.0, 셀러리 == 4.1.0, amqp == 2.4.2

제안 해주세요

우리는 이것을 보거나이 문제와 매우 유사한 것을보기 시작했습니다.

소프트웨어-> 셀러리 : 4.3.0 (rhubarb) kombu : 4.5.0 py : 2.7.12
당구 : 3.6.0.0 redis : 3.2.1

그것은 실제적인 변화없이 하루에 몇 번 발생하기 시작했습니다.
다음 릴리스에서는 최신 버전 인 celery 4.4.0, redis 등으로 업그레이드하고보고 할 것입니다.

(concurrency = 1000 (gevent) & redis as broker)와 함께 발생합니다.
셀러리 == 4.4.0 (절벽)
kombu == 4.6.7
당구 == 3.6.2.0
(py-) redis == 3.4.1

Redis 서버 버전 = 5.0.7
파이썬 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 bits = 64 build = 9435c3c2879311f3
• 셀러리 == 4.4.0
• 당구 == 3.6.1.0
• kombu == 4.6.7
• redis == 3.3.11

이것은 asyncio의 open_connection을 사용하여 TCP 서버에 연결할 때 발생합니다. VPN 내에서 원격 서버에 연결하고 15 분 후에 연결이 끊어집니다. 연결이 유휴 상태이기 때문이라고 생각합니다. 원격 서버 내에서 연결할 때도 같은 일이 발생하지 않습니다. 네트워크와 관련된 것 같습니다.

내 사건을 해결 했어! 어.

셀러리 문제가 아니 었습니다. 4. [234] .0을 포함하여 몇 가지 버전을 사용해 보았고, redis에 몇 가지 버전의 파이썬 인터페이스를 시도했습니다. 그리고 저는 항상 동일한 실패율 (요청 50 만 건의 경우 약 2 ‰)을 더 적었습니다.

해결책은 redis 서버 재구성, 즉 모든 클래스에 대해 클라이언트 출력 버퍼 제한을 비활성화하는 것입니다. redis 문서 에 따르면 :

하드 한계에 도달하거나 소프트 한계에 도달하고 지정된 시간 (연속) 동안 도달 한 상태로 유지되면 클라이언트는 즉시 연결이 끊어집니다.
…
하드 또는 소프트 제한은 모두 0으로 설정하여 비활성화 할 수 있습니다.

여러분 모두에게 도움이되기를 바랍니다. 아니면 내 솔루션을 개선 할 수도 있습니다.

내 사건을 해결 했어! 어.

셀러리 문제가 아니 었습니다. 4. [234] .0을 포함하여 몇 가지 버전을 사용해 보았고, redis에 몇 가지 버전의 파이썬 인터페이스를 시도했습니다. 그리고 저는 항상 동일한 실패율 (요청 50 만 건의 경우 약 2 ‰)을 더 적었습니다.

해결책은 redis 서버 재구성, 즉 모든 클래스에 대해 클라이언트 출력 버퍼 제한을 비활성화하는 것입니다. redis 문서 에 따르면 :

하드 한계에 도달하거나 소프트 한계에 도달하고 지정된 시간 (연속) 동안 도달 한 상태로 유지되면 클라이언트는 즉시 연결이 끊어집니다.
…
하드 또는 소프트 제한은 모두 0으로 설정하여 비활성화 할 수 있습니다.

여러분 모두에게 도움이되기를 바랍니다. 아니면 내 솔루션을 개선 할 수도 있습니다.

이것은 다른 제안이 없었던 저에게도 효과적이었습니다. 감사합니다!

설정 문제가 해결되었음을 확인할 수도 있습니다. @rganowski에 시간을 투자 해 주셔서 감사합니다!

이 방법으로 문제가 해결된다면 좋지만 구성 파일에서 기본값을 제거하기 전에 해당 설정이 무엇을하는지, 왜 기본 구성의 일부인지 아는 것이 좋을 것 같습니다.

@Moulde 구성 파일에서 기본값을 삭제하는 것에 대해 말하는 것이 무엇을 의미하는지 잘 모르겠습니다. 어떤 구성 파일입니까? 내가 지적한 기본 Redis 서버 설정을 변경하는 것을 의미합니까?

또한 그러한 기본값이 존재하는 이유를 알고 싶습니다. 의식이 있었나요? 만약 그렇다면 그들을 포기할 위험은 무엇입니까? 하지만 솔직히 말씀 드리지 않겠습니다. 10MD 작업이 있었는데 3MD를 무료로 추가해야했습니다.

아무도 그것이 문제를 해결한다고 말하지 않았습니다. 나는 내 사건에 대한 해결책을 찾았다 고 말했다. 다른 두 명의 친구들도 그들에게도 효과가 있다고 말했습니다. 나는 그것을 기쁘게 읽었습니다. 하지만 내가 읽은 당신의 말은 "증명"입니다. 내가 잘못?

응용 프로그램에서 테스트하고 효과가 있는지 알려주십시오. 다른 의심을 해결한다면 다른 사람들과 공유하는 것을 잊지 마십시오.

@rganowski 우리가 동의하는 것 같습니다. 네, 제 말이 의미하는 바를 알 수 있습니다. 그런 의미는 아니지만 시스템 기본값을 수정하기 전에 약간의 건전한 회의론을 추가하고 문서에 대한 약간의 비판을 추가해야합니다. -해당 설정이 필요한 이유에 대한 정보가 파일에있는 "무엇을 수행하는지"옆에있는 것이 좋습니다. :)
시간을 내 주셔서 감사합니다. 제 스스로 알아 내지 못했을 것입니다.

Celery 코드에 오류가 없었기 때문에 문제가 종결되었지만 문제이면의 문제는 해결되지 않았습니다. redis 백엔드 설정 문서에 적절한 경고가 추가되어야한다고 생각합니다.

'client-output-buffer-limit'에 대한 인터넷 검색은 많은 흥미로운 기사를 찾을 수 있습니다. 이미 6 년이 된 한 사람은 정말 아름다운 제목 인 The Replication Buffer-How to avoid Devops Headaches를 얻었습니다 . 여기에서 읽을 수 있습니다.

복제 버퍼의 크기를 늘리기 전에 컴퓨터에 충분한 메모리가 있는지 확인해야합니다.

다른 기사에서 클라이언트 버퍼-프로덕션에서 Redis를 사용하기 전에 이것을 확인하십시오! 저자는 말한다 :

기본적으로 일반 클라이언트 (일반 실행 명령)는 요청없이 (푸시 방식으로) 데이터를 수신하지 않기 때문에 제한되지 않고 요청 직후에 비동기 클라이언트 만 데이터가 가능한 것보다 빠르게 요청되는 시나리오를 생성 할 수 있습니다. 읽다.

그게 우리 사건 아닌가요?

나에게 적어도 지금까지는 재구성이 구원으로 밝혀졌습니다. 정말 무겁고 즉각적인 부하에서 새로운 '104'오류가 없습니다.

트윗 담아 가기

안녕, 나는 매우 순진하게 들릴 수 있지만 모든 클래스에 대해 client-output-buffer-limit를 비활성화하기 위해 필요한 수정을 할 수있는 곳을 알려주십시오. 나는 또한 같은 오류가 발생하지만 어떻게 든 귀하의 대답을 해석 할 수 없습니다. 필요한 변경을 할 수 있도록 답변을 자세히 설명해 주시겠습니까? 감사합니다!

Celery 코드에 오류가 없었기 때문에 문제가 종결되었지만 문제이면의 문제는 해결되지 않았습니다. redis 백엔드 설정 문서에 적절한 경고가 추가되어야한다고 생각합니다.

'client-output-buffer-limit'에 대한 인터넷 검색은 많은 흥미로운 기사를 찾을 수 있습니다. 이미 6 년이 된 한 사람은 정말 아름다운 제목 인 The Replication Buffer-How to avoid Devops Headaches를 얻었습니다 . 여기에서 읽을 수 있습니다.

복제 버퍼의 크기를 늘리기 전에 컴퓨터에 충분한 메모리가 있는지 확인해야합니다.

다른 기사에서 클라이언트 버퍼-프로덕션에서 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 및 celery 4.2.0에서 간헐적으로 발생합니다. 패키지 사용자에게 강제하는 것이 아니라 재시도 처리 기능이 내장 된 경우에도 마찬가지입니다.

나는 또한 그것을 경험하고 있습니다. 저는 Celery 4.3.0 및 RabbitMQ 3.3.5를 사용하고 있습니다.