<p>Sellerie-Auslösefehler: [Errno 104] Verbindung von Peer nach dem Start zurückgesetzt</p>

Ich sehe das gleiche Problem mit Sellerie 4.2.0. Ich habe es nicht mit Sellerie 4.1.1. Vor Ort bekomme ich oft, aber nicht immer, den Errno 104. Bei einem Travis-Build scheint er in 4.2.0 konsistenter zu scheitern (und in 4.1.1 erfolgreich zu sein). Ich habe die Zeitabhängigkeit, die @axiaoxin meldet, nicht bemerkt.

Können Sie bitte die Ausgabe des folgenden Befehls bereitstellen:

$ celery -A proj report

hi @georgepsarakis das ist mein

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

In diesem Bericht werden einige Kennwörter nicht durch * ersetzt

Für das, was es wert ist, sehe ich dies auch bei einem sauberen Projekt, bei dem gevent mit rabbitmq verwendet wird. Nachdem wir die Sellerie-Arbeiter für ein paar Minuten gestartet haben, erhalten wir einen Verbindungs-Reset und danach werden keine Aufgaben mehr verbraucht.

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

Habe immer noch das gleiche Problem. (Sellerie 4.2) Es wurde durch Herabstufen der Sellerieversion auf 4.1 behoben, weiß aber nicht, warum dieser Fehler aufgetreten ist.

Könnten Sie versuchen, Sellerie aus dem Master-Zweig mit all seinen Abhängigkeiten vom Master zu installieren und zu sehen, was passiert?

Immer noch diesen Fehler mit Sellerie 4.2.2.

@auvipy Danke, es funktioniert!

@ yuda110 wissen Sie, welche Änderungen an Ihren Abhängigkeiten das Problem behoben haben?

Wir erhalten dieses ConnectionReset-Problem und verwenden Sellerie 4.2.1 mit den folgenden angehefteten Versionen, die mit den Sellerie-Anforderungen kompatibel sind:

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
Oh, ich habe vergessen, diese Antwort zu löschen. Seemed Es schien, dass das Problem nach dem Upgrade der Version (auf 4.2.1) behoben wurde, aber erneut mit einem unbekannten Problem konfrontiert wurde. Schließlich musste ich auf Version 4.0 downgraden.

Ich habe auf 4.1 heruntergestuft und es hat den Fehler behoben. Ich habe 4.3 noch nicht ausprobiert.

Dieser Fehler tritt bei uns ziemlich selten auf, und es stellt sich heraus, dass es sich um eine verkettete Ausnahme handelt, die mit einem ConnectionReset -Fehler vom redis-Client beginnt. Ich werde nur Wiederholungsversuche aktivieren, wenn ein kombu.exceptions.OperationalError ausgelöst wird, da das Celery ChangeLog anzeigt, dass dies ein Fehler ist, der wiederholt werden kann.

Ich wollte nur sagen, dass das Problem in 4.3.0 bei Verwendung von RabbitMQ weiterhin besteht. Der Umzug nach Redis hat das Problem irgendwie behoben.

Wir haben dies behoben, indem wir Wiederholungen mit exponentiellem Backoff durchgeführt haben, wenn ein kombu.exceptions.OperationalError geworfen wird. Diese sollen laut den Unterlagen erneut versucht werden. Das Problem tritt bei uns sehr selten auf, daher sind Wiederholungsversuche eine gute Lösung. Wir sind am 4.2.1.

Hallo,

Ich benutze rabbitmq als Broker und Backend und habe das gleiche Problem.

Hat jemand eine Lösung?

Danke im Voraus.

Gleiches Problem hier. Dies ist für mich zu 100% reproduzierbar. Aus irgendeinem Grund stirbt der Socket an den Broker nach dem scheinbaren Heartbeat-Intervall ab.

Bericht:

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

Ich muss sagen, dass meine Probleme mit dem Upgrade auf Erlang 22.0 begannen. Das kann aber auch nebensächlich sein.

Können Sie eine Lösung vorschlagen? Wenn Sie können, wird dies in 4.4.0rc2 enthalten sein

Ich kann dieses Verhalten in 4.3.0 auch mit gevent worker bestätigen. Der Wechsel von gevent zu prefork scheint das Problem zu lösen. Ich habe versucht, ein Downgrade auf 4.1.1 durchzuführen, aber das scheint unter Python 3.7 nicht zu funktionieren, da eine ältere Version von gevent (1.2.2) erforderlich ist, die unter Python 3.7 nicht einmal kompiliert werden kann. Ich habe festgestellt, dass zu Beginn des Problems in den rabbitmq-Protokollen die folgende Meldung angezeigt wird:

missed heartbeats from client, timeout: 60s

Interessanterweise nimmt der Mitarbeiter trotz des Herzschlags immer noch Aufgaben auf und verarbeitet sie einwandfrei. Es ist nur so, dass celery inspect die ganze Zeit flower zeigt weiterhin Informationen im Dashboard für den Worker an, aber wenn Sie auf den Worker selbst klicken, wird der Fehler 404 Not Found angezeigt, und Fehler in den Blumenprotokollen im Zusammenhang mit Sellerie-Inspektionsbefehlen:

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] 

Brauchen Sie jemanden, der dies auf Sellerie 4.4.0rc3 + kombu 4.6.3 überprüft?

Wird besorgt. Zu Ihrer Information, Sellerie 4.4.0rc3 erfordert Kombu 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 scheint dieses Problem zu beheben. Ich habe es länger als 5 Minuten ohne Heartbeat-Fehler mit dem Gevent-Worker laufen lassen.

kombu 4.6.3 ist auch kompatibel

In diesem Fall möchten Sie möglicherweise die Anforderungsdatei für das Sellerieprojekt aktualisieren.

Aber was haben wir geändert?

Ich würde auch gerne einen Einblick in die Änderungen erhalten, die dazu geführt haben, dass dies geschlossen wurde, oder einen Link zu einem PR / Code / etc. Wir sind betroffen und mildern es (Prefork, Rabbitmq, Sellerie 4.3), indem wir den Herzschlag deaktivieren, was nicht optimal ist.

@auvipy Ping?

Ok, 4.4.0rc3 scheint dieses Problem zu beheben. Ich habe es länger als 5 Minuten ohne Heartbeat-Fehler mit dem Gevent-Worker laufen lassen.

Das Problem wurde aufgrund dieses Feedbacks geschlossen

@auvipy Es scheint, dass es mehrere Probleme gibt, die zu ähnlichen Fehlern führen. Es wäre großartig, wenn Sie versuchen würden, den Fehler lokal zu reproduzieren, möglicherweise mit einigen älteren Sellerieversionen, bevor Sie das Problem beheben.

Es wird empfohlen, den Hauptzweig auszuprobieren.

Ich schlage vor, den Fehler mit einer der früheren Versionen (z. B. 4.1, 4.2, 4.3) zu reproduzieren und sicherzustellen, dass das Problem allein durch ein Upgrade auf 4.4 behoben wurde. Das Schließen des Fehlers ohne Ihre eigene Bestätigung - basierend auf dem Feedback einer einzelnen Person - scheint etwas voreilig.

Da Sie mit dem Problem konfrontiert sind, sollten Sie als erster überprüfen, wie Sie vorgeschlagen haben. @czyzby

Sie sollten der Erste sein, der überprüft, wie Sie vorgeschlagen haben

_ "Sollte"? _;) Wenn es jemanden gibt, der sich um die Qualität des Projekts kümmern sollte, sind es die offiziellen Betreuer. Ich bin dankbar, dass Sie Ihre Software kostenlos anbieten, aber Sie können nicht realistisch erwarten, dass alle Ihre Benutzer zum Projekt beitragen.

Wie auch immer, ich habe nicht mehr die Konfiguration, die das Problem verursacht hat, aber ich denke, das Problem blieb auch bei leeren Warteschlangen ohne definierte Aufgaben bestehen, sodass es möglicherweise einfach zu reproduzieren ist. Seitdem habe ich das Problem mit einer Problemumgehung durch Migration auf Redis behoben, da unser Team die Technologien zu diesem Zeitpunkt leicht ändern konnte. Und um ganz ehrlich zu sein, erwägen wir einen Wechsel zu RQ aufgrund anderer Probleme mit Sellerie.

4.4.0rc4 scheint auch dieses Problem zu lösen,

Jeder andere, der es überprüfen kann, repariert es durch Sellerie == 4.4.0rc4

@auvipy Ich war auf 4.3.0 mit dem gelegentlichen Connection reset . Keine Probleme mehr mit 4.4.0rc4 für mich.

Jeder andere, der es überprüfen kann, repariert es durch Sellerie == 4.4.0rc4

Das Problem trat häufig bei 4.3.0 auf - bei 4.4.0rc4 tritt das Problem weitaus seltener auf -, aber von Zeit zu Zeit treten Standbilder auf.
Ich verwende Redis-Server 5.0.6 und Python Redis Client 3.3.11 mit ~ 14 regelmäßigen Aufgaben (alle 30 Sekunden).
Deshalb möchte ich Sie bitten, das Problem erneut zu öffnen.
Vielen Dank!

Das Problem trat häufig bei 4.3.0 auf - bei 4.4.0rc4 tritt das Problem weitaus seltener auf -, aber von Zeit zu Zeit treten Standbilder auf.
Ich verwende Redis-Server 5.0.6 und Python Redis Client 3.3.11 mit ~ 14 regelmäßigen Aufgaben (alle 30 Sekunden).
Deshalb möchte ich Sie bitten, das Problem erneut zu öffnen.
Vielen Dank

In der Tat tritt das Problem immer noch bei den Standardeinstellungen auf. Wie in anderen Threads erwähnt, scheint es jedoch hilfreich zu sein, broker_heartbeat = 0 in celeryconfig.py festzulegen.

Selbst nach dem Upgrade auf Sellerie 4.4.0rc4 und dem Hinzufügen von CELERY_BROKER_HEARTBEAT = 0 in celery.py scheint sich für mich nicht viel zu ändern, und es wird immer noch der Fehler angezeigt.

Das Problem wurde nach dem Downgrade von Sellerie 4.2.0 auf 4.10 noch nicht gelöst

Folgende Versionen werden in unserem Projekt verwendet:
Billard == 3.5.0.2, Kombu == 4.1.0, Sellerie == 4.1.0, Amqp == 2.4.2

bitte vorschlagen

Wir haben angefangen, dies zu sehen, oder etwas, das diesem Problem sehr ähnlich ist.

Software -> Sellerie: 4.3.0 (Rhabarber) Kombu: 4.5.0 py: 2.7.12
Billard: 3.6.0.0 Redis: 3.2.1

Es trat einige Male am Tag auf, ohne wirkliche Veränderungen.
In unserer nächsten Version werden wir versuchen, auf die neuesten Versionen, Sellerie 4.4.0, Redis usw. zu aktualisieren und einen Bericht zu erstellen.

Passiert für mich mit (Parallelität = 1000 (gevent) & redis als Broker):
Sellerie == 4.4.0 (Klippen)
kombu == 4.6.7
Billard == 3.6.2.0
(py-) redis == 3.4.1

Redis Server Version = 5.0.7
Python 3.7.3

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

• Alle 10 Sekunden werden 7 Aufgaben ausgeführt.
• Der Fehler tritt nur im Sellerie-Schlag auf, und sehr selten tritt ein Fehler in weniger als 3 Fällen pro Stunde auf.

Stichworte

• Logger: celery.beat
• Laufzeit: CPython 3.7.5

Umgebung

• Linux-4.15.0-1060-aws-x86_64-with-Ubuntu-18.04-bionic
• Python 3.7.5 (Standard, 7. November 2019, 10:50:52) [GCC 8.3.0]
• Redis Server v = 4.0.9 sha = 00000000: 0 malloc = jemalloc-3.6.0 Bits = 64 build = 9435c3c2879311f3
• Sellerie == 4.4.0
• Billard == 3.6.1.0
• kombu == 4.6.7
• redis == 3.3.11

Dies passiert mir, wenn ich über open_connection von asyncio eine Verbindung zu einem TCP-Server herstelle. 15 Minuten nachdem ich eine Verbindung zum Remote-Server in unserem VPN hergestellt habe, wird die Verbindung getrennt. Ich vermute, das liegt daran, dass die Verbindung inaktiv ist. Das Gleiche passiert nicht, wenn ich eine Verbindung vom Remote-Server aus herstelle. Dies scheint netzwerkbezogen zu sein.

Ich habe meinen Fall gelöst! Uff.

Es war kein Sellerieproblem. Ich habe einige Versionen davon ausprobiert, einschließlich 4. [234] .0, und ich habe einige Versionen von Python-Schnittstellen ausprobiert, um sie zu redis. Und ich hatte immer, weniger, die gleiche Fehlerquote (ungefähr 2 ‰ für 0,5 Millionen Anfragen)

Die Lösung bestand in der Neukonfiguration des Redis-Servers, dh dem Deaktivieren des Client-Ausgabepuffer-Limits für alle Klassen. Laut Redis-Dokumentation :

Ein Client wird sofort getrennt, sobald das harte Limit erreicht ist oder wenn das weiche Limit erreicht ist und für die angegebene Anzahl von Sekunden (kontinuierlich) erreicht bleibt.
…
Sowohl die harte als auch die weiche Grenze können deaktiviert werden, indem sie auf Null gesetzt werden.

Ich hoffe, es wird auch Ihnen allen helfen. Oder vielleicht verbessern Sie meine Lösung.

Ich habe meinen Fall gelöst! Uff.

Es war kein Sellerieproblem. Ich habe einige Versionen davon ausprobiert, einschließlich 4. [234] .0, und ich habe einige Versionen von Python-Schnittstellen ausprobiert, um sie zu redis. Und ich hatte immer, weniger, die gleiche Fehlerquote (ungefähr 2 ‰ für 0,5 Millionen Anfragen)

Die Lösung bestand in der Neukonfiguration des Redis-Servers, dh dem Deaktivieren des Client-Ausgabepuffer-Limits für alle Klassen. Laut Redis-Dokumentation :

Ein Client wird sofort getrennt, sobald das harte Limit erreicht ist oder wenn das weiche Limit erreicht ist und für die angegebene Anzahl von Sekunden (kontinuierlich) erreicht bleibt.
…
Sowohl die harte als auch die weiche Grenze können deaktiviert werden, indem sie auf Null gesetzt werden.

Ich hoffe, es wird auch Ihnen allen helfen. Oder vielleicht verbessern Sie meine Lösung.

Dies funktionierte auch bei mir, wo keiner der anderen Vorschläge dies tat. Vielen Dank!

Ich kann auch bestätigen, dass das Problem für mein Setup behoben wurde! Vielen Dank, dass Sie sich Zeit für dieses @rganowski genommen haben!

Großartig, wenn dies das Problem behebt, aber bevor ich anfange, Standardeinstellungen aus der Konfigurationsdatei zu entfernen, wäre es großartig zu wissen, was diese Einstellung bewirkt und warum sie Teil der Standardkonfiguration ist.

@Moulde Ich bin mir nicht ganz sicher, was Sie unter dem Löschen der Standardeinstellungen aus der Konfigurationsdatei verstehen. Welche Konfigurationsdatei? Meinen Sie damit, die Standardeinstellungen des Redis-Servers zu ändern, auf die ich hingewiesen habe?

Ich würde auch gerne wissen, warum solche Standardeinstellungen existieren. War das bei Bewusstsein? Wenn ja, wie hoch ist das Risiko, sie aufzugeben? Aber um ehrlich zu sein, werde ich das nicht überprüfen. Ich hatte 10MD Aufgabe, ich musste 3MD kostenlos hinzufügen.

Niemand hat gesagt, dass dies das Problem behebt. Ich sagte, dass ich eine Lösung für meinen Fall gefunden habe. Zwei andere Homies sagten, dass es auch für sie funktioniert. Ich habe das gerne gelesen. Aber deine Worte habe ich so gelesen: "beweise es". Liege ich falsch?

Bitte testen Sie es in Ihrer Bewerbung und lassen Sie uns wissen, ob es für Sie funktioniert. Wenn Sie andere Zweifel lösen, vergessen Sie nicht, sie mit anderen zu teilen.

@rganowski Es hört sich so an, als
Und danke für die Zeit, die Sie dafür aufgewendet haben, ich hätte das nicht alleine herausgefunden.

Das Problem ist geschlossen, da im Sellerie-Code kein Fehler aufgetreten ist, das Problem hinter dem Problem jedoch nicht behoben ist. Ich denke, dass eine angemessene Warnung in der Dokumentation der Redis-Backend-Einstellungen hinzugefügt werden sollte.

Wenn wir nach 'Client-Output-Buffer-Limit' googeln, finden wir viele interessante Artikel. Einer, der jetzt schon 6 Jahre alt ist, hat - in den Ergebnissen - einen wirklich schönen Titel. Der Replikationspuffer - Wie man Devops-Kopfschmerzen vermeidet . Dort können wir lesen:

Bevor Sie die Größe der Replikationspuffer erhöhen, müssen Sie sicherstellen, dass auf Ihrem Computer genügend Speicher vorhanden ist.

In einem anderen Artikel Client Buffers-Bevor Sie Redis in die Produktion nehmen, überprüfen Sie dies! Autor sagt:

Standardmäßig sind normale Clients (normale Ausführungsbefehle) nicht eingeschränkt, da sie keine Daten ohne Aufforderung (auf Push-Weise) empfangen, sondern nur nach einer Anforderung. Daher können nur asynchrone Clients ein Szenario erstellen, in dem Daten schneller als möglich angefordert werden lesen.

Ist das nicht unser Fall?

Zumindest bis jetzt erwies sich die Neukonfiguration für mich als Erlösung. Keine neuen '104'-Fehler bei einer wirklich schweren und sofortigen Belastung.

@rganowski @Moulde @ CM2Walki

Hallo, ich mag sehr naiv klingen, aber können Sie mir bitte sagen, wo ich die erforderlichen Änderungen vornehmen kann, um das Client-Ausgabepuffer-Limit für alle Klassen zu deaktivieren. Da ich auch den gleichen Fehler bekomme, aber irgendwie nicht in der Lage bin, Ihre Antwort zu interpretieren. Können Sie bitte Ihre Antwort näher erläutern, damit ich die notwendigen Änderungen vornehmen kann? Vielen Dank!

Das Problem ist geschlossen, da im Sellerie-Code kein Fehler aufgetreten ist, das Problem hinter dem Problem jedoch nicht behoben ist. Ich denke, dass eine angemessene Warnung in der Dokumentation der Redis-Backend-Einstellungen hinzugefügt werden sollte.

Wenn wir nach 'Client-Output-Buffer-Limit' googeln, finden wir viele interessante Artikel. Einer, der jetzt schon 6 Jahre alt ist, hat - in den Ergebnissen - einen wirklich schönen Titel. Der Replikationspuffer - Wie man Devops-Kopfschmerzen vermeidet . Dort können wir lesen:

Bevor Sie die Größe der Replikationspuffer erhöhen, müssen Sie sicherstellen, dass auf Ihrem Computer genügend Speicher vorhanden ist.

In einem anderen Artikel Client Buffers-Bevor Sie Redis in die Produktion nehmen, überprüfen Sie dies! Autor sagt:

Standardmäßig sind normale Clients (normale Ausführungsbefehle) nicht eingeschränkt, da sie keine Daten ohne Aufforderung (auf Push-Weise) empfangen, sondern nur nach einer Anforderung. Daher können nur asynchrone Clients ein Szenario erstellen, in dem Daten schneller als möglich angefordert werden lesen.

Ist das nicht unser Fall?

Zumindest bis jetzt erwies sich die Neukonfiguration für mich als Erlösung. Keine neuen '104'-Fehler bei einer wirklich schweren und sofortigen Belastung.

Ich schätze eine PR zur Verbesserung des Dokuments sehr

@ girijesh97 @auvipy

In 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 Wieder mag ich sehr naiv klingen, aber ich habe eine Django-Anwendung, in der ich Sellerie (Version 4.4.2) verwende und auf das Verbindungsfehlerproblem stoße. Können Sie uns bitte beim Auffinden oder Erstellen dieser redis.conf-Datei helfen? Muss ich diese Datei in meiner Anwendung erstellen oder ist sie in einem Paket verfügbar?

Wenn Ihr Fall der gleiche ist, über den wir gesprochen haben, verwendet Ihr Sellerie das Backend der Redis Server-Ergebnisse. Die Datei, die ich erwähnt habe, ist eine Standard-Redis-Server-Konfigurationsdatei. Deshalb ist dies in der Tat kein Sellerieproblem, sondern eine Nebenwirkung.

@auvipy Gibt es einen Fix für RabbitMQ als Broker und Ergebnis-Backend für dasselbe Problem

Auch dieses Problem tritt zeitweise bei RabbitMQ und Sellerie 4.2.0 auf. Selbst wenn es in die Wiederholungsbehandlung integriert ist, anstatt dies den Benutzern des Pakets aufzuzwingen.

Ich erlebe es auch. Ich bin auf Sellerie 4.3.0 und RabbitMQ 3.3.5.