<p>error de aumento de apio: [Errno 104] Conexión restablecida por el par después de iniciado</p>

Veo el mismo problema con Celery 4.2.0. No lo tengo con Apio 4.1.1. A nivel local, a menudo, pero no siempre, obtengo el Errno 104. En una compilación de travis, parece fallar más consistentemente en 4.2.0 (y tener éxito en 4.1.1). No he notado la dependencia del tiempo que informa @axiaoxin .

¿Puede proporcionar el resultado del siguiente comando:

$ celery -A proj report

hola @georgepsarakis este es mi informe

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

como este informe, algunas dosis de contraseña no se pueden reemplazar con *

Por lo que vale, estoy viendo esto también con un proyecto limpio usando gevent con rabbitmq. Después de iniciar los trabajadores de apio durante un par de minutos, recibiremos un restablecimiento de la conexión y no se consumirán tareas a partir de entonces.

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

Todavía tengo el mismo problema hasta ahora. (Apio 4.2) Se resolvió rebajando la versión de apio a 4.1, pero no sé por qué ocurrió este error.

¿Podrías intentar instalar apio desde la rama maestra con todas sus dependencias desde la maestra y ver qué está pasando?

Sigo recibiendo este error con Celery 4.2.2.

@auvipy ¡ Gracias, funciona!

@ yuda110 ¿sabe qué cambios en sus dependencias resolvieron el problema?

Tenemos este problema de ConnectionReset y estamos usando Celery 4.2.1 con las siguientes versiones fijadas que son compatibles con los requisitos de apio:

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

@carloscapps
Oh, olvidé borrar esa respuesta ☹️☹️ Parecía que el problema se resolvió después de actualizar la versión (a 4.2.1), pero me enfrenté a un problema desconocido nuevamente. Finalmente tuve que degradar a la versión 4.0.

Bajé la calificación a 4.1 y solucionó el error. Sin embargo, todavía no he probado la versión 4.3.

Este error ocurre muy raramente para nosotros, y resulta que es una excepción encadenada que comienza con un error ConnectionReset del cliente de redis. Voy a habilitar los reintentos cuando se lanza un kombu.exceptions.OperationalError , porque el Apio ChangeLog indica que se trata de un error que se puede reintentar.

Solo quería decir que el problema persiste en 4.3.0 cuando se usa RabbitMQ. De alguna manera, mudarse a Redis solucionó el problema.

Resolvimos esto haciendo reintentos con retroceso exponencial cada vez que se lanza un kombu.exceptions.OperationalError . Esos están destinados a ser reintentados, según los documentos. El problema ocurre muy raramente para nosotros, por lo que los reintentos son una buena solución. Estamos en 4.2.1.

Hola,

Estoy usando rabbitmq como corredor y backend y tengo el mismo problema.

¿Alguien tiene una solución?

Gracias por adelantado.

El mismo problema aquí. Esto es 100% reproducible para mí. Por alguna razón, el conector del corredor se interrumpe después de lo que parece ser el intervalo de latidos.

informe:

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

Debo decir que mis problemas comenzaron cuando actualicé a Erlang 22.0. Pero eso también puede ser incidental.

¿Puede sugerir alguna solución? Si puede, se incluirá en 4.4.0rc2

También puedo confirmar este comportamiento en 4.3.0 con gevent worker. El cambio de gevent a prefork parece resolverlo. Intenté degradar a 4.1.1 pero eso no parece funcionar en Python 3.7 porque requiere una versión anterior de gevent (1.2.2) que ni siquiera se compilará en Python 3.7. Me di cuenta de que cuando comienza el problema, los registros de rabbitmq muestran este mensaje:

missed heartbeats from client, timeout: 60s

Curiosamente, a pesar de que los latidos del corazón fallan, el trabajador aún retoma las tareas y las procesa bien. Es solo que celery inspect comandos todo el tiempo de espera hasta que se reinicia el trabajador. flower aún muestra información en el tablero para el trabajador, pero al hacer clic en el trabajador se obtiene un error 404 No encontrado y fallas en los registros de flores relacionadas con los comandos de inspección de apio:

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] 

¿Necesita que alguien verifique esto en apio 4.4.0rc3 + kombu 4.6.3?

Servirá. Para su información, el apio 4.4.0rc3 requiere 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 parece resolver este problema. Lo dejé durante más de 5 minutos sin errores de latido usando el trabajador gevent.

kombu 4.6.3 también es compatible

Si ese es el caso, es posible que desee actualizar el archivo de requisitos en el proyecto de apio.

Pero, ¿qué cambiamos?

También me encantaría tener una idea de los cambios que causaron que esto se cerrara, o un enlace a un PR / código / etc. Nos afecta y lo mitiga (prefork, rabbitmq, celery 4.3) desactivando los latidos del corazón, que no son óptimos.

@auvipy Ping?

Ok, 4.4.0rc3 parece resolver este problema. Lo dejé durante más de 5 minutos sin errores de latido usando el trabajador gevent.

el problema se cerró en función de estos comentarios

@auvipy Parece que hay varios problemas que conducen a errores similares. Sería genial si intentara reproducir el error localmente, posiblemente con algunas versiones anteriores de Apio, antes de resolver el problema.

se le sugiere que pruebe la rama maestra.

Estoy sugiriendo reproducir el error con una de las versiones anteriores (por ejemplo, 4.1, 4.2, 4.3) y asegurarse de que la actualización a 4.4 solo solucione el problema. Cerrar el error sin su propia verificación, basado en los comentarios de una sola persona, parece un poco apresurado.

dado que enfrenta el problema, debe ser el primero en verificar como sugirió. @czyzby

debe ser el primero en verificar como sugirió

_ "¿Debería"? _;) Si hay alguien a quien _debería_ preocuparse por la calidad del proyecto, son los mantenedores oficiales. Estoy agradecido de que ofrezca su software de forma gratuita, pero no puede esperar de manera realista que todos sus usuarios contribuyan al proyecto.

De todos modos, ya no tengo la configuración que causó el problema, pero creo que el problema persistió incluso en el caso de colas vacías sin tareas definidas, por lo que podría ser fácil de reproducir. Desde entonces, resolví el problema con una solución alternativa al migrar a Redis, ya que nuestro equipo podría cambiar fácilmente las tecnologías en ese momento. Y, para ser completamente honesto, estamos considerando un cambio a RQ debido a otros problemas con Celery.

4.4.0rc4 también parece resolver este problema,

cualquier otra persona que pueda comprobarlo está arreglado por apio == 4.4.0rc4

@auvipy Estaba en 4.3.0 con el ocasional Connection reset . No más problemas con 4.4.0rc4 para mí.

cualquier otra persona que pueda comprobarlo está arreglado por apio == 4.4.0rc4

Obtuvo el problema en 4.3.0 con bastante frecuencia; con 4.4.0rc4, el problema ocurre con mucha menos frecuencia, pero las imágenes fijas ocurren de vez en cuando.
Estoy usando redis-server 5.0.6 y python redis Client 3.3.11 con ~ 14 tareas periódicas (cada 30 segundos).
Así que le pido que vuelva a abrir el problema.
¡Gracias!

Obtuvo el problema en 4.3.0 con bastante frecuencia; con 4.4.0rc4, el problema ocurre con mucha menos frecuencia, pero las imágenes fijas ocurren de vez en cuando.
Estoy usando redis-server 5.0.6 y python redis Client 3.3.11 con ~ 14 tareas periódicas (cada 30 segundos).
Así que le pido que vuelva a abrir el problema.
Gracias

De hecho, el problema persiste con la configuración predeterminada. Sin embargo, como se menciona en otros hilos, la configuración de broker_heartbeat = 0 en celeryconfig.py parece ayudar.

Incluso después de actualizar a apio 4.4.0rc4 y agregar CELERY_BROKER_HEARTBEAT = 0 en celery.py, nada parece cambiar mucho para mí, todavía aparece el error.

el problema no se resolvió aún después de la degradación de apio 4.2.0 a 4.10

Las siguientes versiones se utilizan en nuestro proyecto:
billar == 3.5.0.2, kombu == 4.1.0, apio == 4.1.0, amqp == 2.4.2

Por favor recomiende

Empezamos a ver esto, o algo que se parece mucho a este problema.

software -> apio: 4.3.0 (ruibarbo) kombu: 4.5.0 py: 2.7.12
billar: 3.6.0.0 redis: 3.2.1

Comenzó a ocurrir varias veces al día, sin cambios reales.
Para nuestra próxima versión, intentaremos actualizar a las versiones más recientes, apio 4.4.0, redis, etc. y le informaremos.

Me sucede con (concurrencia = 1000 (gevent) y redis como corredor):
apio == 4.4.0 (acantilados)
kombu == 4.6.7
billar == 3.6.2.0
(py-) redis == 3.4.1

Versión del servidor Redis = 5.0.7
Python 3.7.3

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

• 7 tareas están configuradas para ejecutarse cada 10 segundos.
• El error se produce solo en el ritmo del apio y, en muy raras ocasiones, se produce un error en menos de 3 casos por hora.

Etiquetas

• registrador: apio.beat
• tiempo de ejecución: CPython 3.7.5

Ambiente

• Linux-4.15.0-1060-aws-x86_64-con-Ubuntu-18.04-bionic
• Python 3.7.5 (predeterminado, 7 de noviembre de 2019, 10:50:52) [GCC 8.3.0]
• Servidor Redis v = 4.0.9 sha = 00000000: 0 malloc = jemalloc-3.6.0 bits = 64 build = 9435c3c2879311f3
• apio == 4.4.0
• billar == 3.6.1.0
• kombu == 4.6.7
• redis == 3.3.11

Esto me sucede cuando me conecto a un servidor TCP usando open_connection de asyncio. 15 minutos después de que me conecto al servidor remoto dentro de nuestra VPN, me desconecta. Sospecho que esto se debe a que la conexión está inactiva. No sucede lo mismo cuando me conecto desde el servidor remoto. Esto parece estar relacionado con la red.

¡Resolví mi caso! Uff.

No fue un problema de apio. Probé algunas versiones, incluida la 4. [234] .0, y probé algunas versiones de interfaces de Python para redis. Y siempre he tenido, más menos, la misma tasa de fallos (alrededor de 2 ‰ por 0,5 millones de solicitudes)

La solución estaba en la reconfiguración del servidor de redis, es decir, deshabilitar el límite de búfer de salida de cliente para todas las clases. Según la documentación de redis :

Un cliente se desconecta inmediatamente una vez que se alcanza el límite estricto, o si se alcanza el límite suave y permanece alcanzado durante el número especificado de segundos (continuamente).
...
Tanto el límite rígido como el blando se pueden desactivar poniéndolos a cero.

Espero que también les ayude a todos. O tal vez mejore mi solución.

¡Resolví mi caso! Uff.

No fue un problema de apio. Probé algunas versiones, incluida la 4. [234] .0, y probé algunas versiones de interfaces de Python para redis. Y siempre he tenido, más menos, la misma tasa de fallos (alrededor de 2 ‰ por 0,5 millones de solicitudes)

La solución estaba en la reconfiguración del servidor de redis, es decir, deshabilitar el límite de búfer de salida de cliente para todas las clases. Según la documentación de redis :

Un cliente se desconecta inmediatamente una vez que se alcanza el límite estricto, o si se alcanza el límite suave y permanece alcanzado durante el número especificado de segundos (continuamente).
...
Tanto el límite rígido como el blando se pueden desactivar poniéndolos a cero.

Espero que también les ayude a todos. O tal vez mejore mi solución.

Esto también funcionó para mí, donde ninguna de las otras sugerencias lo hizo. ¡Gracias!

¡También puedo confirmar que resolvió el problema de mi configuración! ¡Gracias por dedicar tiempo a este @rganowski!

Genial si esto soluciona el problema, pero antes de comenzar a eliminar los valores predeterminados del archivo de configuración, creo que sería genial saber qué hace esa configuración y por qué es parte de la configuración predeterminada.

@Moulde No estoy muy seguro de a qué te refieres cuando hablas de eliminar los valores predeterminados del archivo de configuración. ¿Qué archivo de configuración? ¿Te refieres a cambiar la configuración predeterminada del servidor Redis que señalé?

También me gustaría saber por qué existen tales valores predeterminados. ¿Eso fue consciente? Si es así, ¿cuál es el riesgo de renunciar a ellos? Pero, para ser honesto, no voy a comprobarlo. Tenía una tarea de 10MD, tenía que agregar 3MD gratis.

Nadie dijo que eso soluciona el problema. Dije que encontré una solución para mi caso. Otros dos amigos dijeron que también les funciona. Lo leí con mucho gusto. Pero tus palabras las leo de esa manera: "pruébalo". ¿Me equivoco?

Por favor, pruébelo en su aplicación y háganos saber si le funciona. Si resuelves otras dudas, no olvides compartirlas con los demás.

@rganowski Parece que estamos de acuerdo, y sí, veo lo que quieres decir con mi redacción, no fue así, sino más bien para agregar un poco de escepticismo saludable antes de modificar los valores predeterminados del sistema, y ​​tal vez un poco de crítica a la documentación. - como una pequeña información sobre por qué se necesita esa configuración sería genial, al lado de la parte "qué hace" que está en el archivo :)
Y gracias por el tiempo que dedicaste a esto, no me habría dado cuenta de eso por mi cuenta.

El problema está cerrado, porque no hubo ningún error en el código de Apio, pero el problema detrás del problema no está resuelto. Creo que se debe agregar una advertencia adecuada en la documentación de configuración de backend de redis.

Buscando en Google 'client-output-buffer-limit' podemos encontrar muchos artículos interesantes. Uno, que ya tiene 6 años, tiene, en resultados, un título realmente hermoso The Replication Buffer: Cómo evitar los dolores de cabeza de Devops . Allí podemos leer:

Antes de aumentar el tamaño de los búferes de replicación, debe asegurarse de tener suficiente memoria en su máquina.

En algún otro artículo Client Buffers: ¡antes de llevar Redis a producción, compruebe esto! autor dice:

De forma predeterminada, los clientes normales (comandos de ejecución normales) no están limitados porque no reciben datos sin preguntar (de forma push), sino justo después de una solicitud, por lo que solo los clientes asincrónicos pueden crear un escenario en el que los datos se soliciten más rápido de lo que pueden. leer.

¿No es ese nuestro caso?

Para mí, al menos hasta ahora, la reconfiguración resultó ser la salvación. Sin nuevos errores '104', con una carga realmente pesada e instantánea.

@rganowski @Moulde @ CM2Walki

Hola, puedo sonar muy ingenuo, pero ¿podría decirme dónde puedo hacer la modificación necesaria para deshabilitar el límite de búfer de salida del cliente para todas las clases? Como también recibo el mismo error, pero de alguna manera no puedo interpretar su respuesta. Entonces, ¿podría explicar más detalladamente su respuesta para que pueda hacer los cambios necesarios? ¡Gracias!

El problema está cerrado, porque no hubo ningún error en el código de Apio, pero el problema detrás del problema no está resuelto. Creo que se debe agregar una advertencia adecuada en la documentación de configuración de backend de redis.

Buscando en Google 'client-output-buffer-limit' podemos encontrar muchos artículos interesantes. Uno, que ya tiene 6 años, tiene, en resultados, un título realmente hermoso The Replication Buffer: Cómo evitar los dolores de cabeza de Devops . Allí podemos leer:

Antes de aumentar el tamaño de los búferes de replicación, debe asegurarse de tener suficiente memoria en su máquina.

En algún otro artículo Client Buffers: ¡antes de llevar Redis a producción, compruebe esto! autor dice:

De forma predeterminada, los clientes normales (comandos de ejecución normales) no están limitados porque no reciben datos sin preguntar (de forma push), sino justo después de una solicitud, por lo que solo los clientes asincrónicos pueden crear un escenario en el que los datos se soliciten más rápido de lo que pueden. leer.

¿No es ese nuestro caso?

Para mí, al menos hasta ahora, la reconfiguración resultó ser la salvación. Sin nuevos errores '104', con una carga realmente pesada e instantánea.

Realmente aprecio una mejora de doc PR

@ girijesh97 @auvipy

En 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 De nuevo, puedo sonar muy ingenuo, pero tengo la aplicación Django en la que estoy usando apio (versión 4.4.2) y me enfrento al problema del error de conexión. ¿Puede ayudarnos a localizar o crear este archivo redis.conf? ¿Necesito crear este archivo en mi aplicación o está disponible en algún paquete?

Si su caso es el mismo, del que estábamos hablando, su apio está usando el backend de resultados del servidor redis. El archivo que he mencionado es el archivo de configuración del servidor redis estándar. Es por eso que, de hecho, esto no es un problema de apio, sino un efecto secundario.

@auvipy ¿Existe una solución para RabbitMQ como corredor y backend de resultados para el mismo problema? Ver esto en 4.4 también en tareas de ejecución prolongada. La corrección anterior es solo para el backend de Redis.

También viendo que este problema ocurre de forma intermitente con RabbitMQ y apio 4.2.0. Incluso si está integrado en el manejo de reintentos en lugar de forzarlo a los usuarios del paquete.

También lo estoy experimentando. Estoy en Celery 4.3.0 y RabbitMQ 3.3.5.