Celery: Se perdió la conexión con el corredor. Intentando restablecer la conexión ...

@dharanpdarsana ¿Tiene redis funcionando? Así es como puede validar:

$ redis-cli                                                                
redis 127.0.0.1:6379> ping
PONG
redis 127.0.0.1:6379> set mykey somevalue
OK
redis 127.0.0.1:6379> get mykey
"somevalue"

@ jpatel3 redis se está ejecutando y el 90% de las conexiones se realizan sin ningún problema

También (de repente) estoy experimentando un error de tubería rota.
Estaba funcionando perfectamente bien antes. Olvidé lo que instalé o hice para activar esto.

[2017-05-22 17:18:10,939: INFO/MainProcess] Connected to amqp://user123:**@192.168.99.100:5672//
[2017-05-22 17:18:10,955: INFO/MainProcess] mingle: searching for neighbors
[2017-05-22 17:18:10,965: WARNING/MainProcess] consumer: Connection to broker lost. Trying to re-establish the connection...
Traceback (most recent call last):
  File "/Users/richmond/Projects/backend/env/lib/python3.6/site-packages/celery/worker/consumer/consumer.py", line 318, in start
    blueprint.start(self)
  File "/Users/richmond/Projects/backend/env/lib/python3.6/site-packages/celery/bootsteps.py", line 119, in start
    step.start(parent)
  File "/Users/richmond/Projects/backend/env/lib/python3.6/site-packages/celery/worker/consumer/mingle.py", line 38, in start
    self.sync(c)
  File "/Users/richmond/Projects/backend/env/lib/python3.6/site-packages/celery/worker/consumer/mingle.py", line 42, in sync
    replies = self.send_hello(c)
  File "/Users/richmond/Projects/backend/env/lib/python3.6/site-packages/celery/worker/consumer/mingle.py", line 55, in send_hello
    replies = inspect.hello(c.hostname, our_revoked._data) or {}
  File "/Users/richmond/Projects/backend/env/lib/python3.6/site-packages/celery/app/control.py", line 129, in hello
    return self._request('hello', from_node=from_node, revoked=revoked)
  File "/Users/richmond/Projects/backend/env/lib/python3.6/site-packages/celery/app/control.py", line 81, in _request
    timeout=self.timeout, reply=True,
  File "/Users/richmond/Projects/backend/env/lib/python3.6/site-packages/celery/app/control.py", line 436, in broadcast
    limit, callback, channel=channel,
  File "/Users/richmond/Projects/backend/env/lib/python3.6/site-packages/kombu/pidbox.py", line 315, in _broadcast
    serializer=serializer)
  File "/Users/richmond/Projects/backend/env/lib/python3.6/site-packages/kombu/pidbox.py", line 290, in _publish
    serializer=serializer,
  File "/Users/richmond/Projects/backend/env/lib/python3.6/site-packages/kombu/messaging.py", line 181, in publish
    exchange_name, declare,
  File "/Users/richmond/Projects/backend/env/lib/python3.6/site-packages/kombu/messaging.py", line 194, in _publish
    [maybe_declare(entity) for entity in declare]
  File "/Users/richmond/Projects/backend/env/lib/python3.6/site-packages/kombu/messaging.py", line 194, in <listcomp>
    [maybe_declare(entity) for entity in declare]
  File "/Users/richmond/Projects/backend/env/lib/python3.6/site-packages/kombu/messaging.py", line 102, in maybe_declare
    return maybe_declare(entity, self.channel, retry, **retry_policy)
  File "/Users/richmond/Projects/backend/env/lib/python3.6/site-packages/kombu/common.py", line 125, in maybe_declare
    return _maybe_declare(entity, declared, ident, channel, orig)
  File "/Users/richmond/Projects/backend/env/lib/python3.6/site-packages/kombu/common.py", line 131, in _maybe_declare
    entity.declare(channel=channel)
  File "/Users/richmond/Projects/backend/env/lib/python3.6/site-packages/kombu/entity.py", line 185, in declare
    nowait=nowait, passive=passive,
  File "/Users/richmond/Projects/backend/env/lib/python3.6/site-packages/amqp/channel.py", line 630, in exchange_declare
    wait=None if nowait else spec.Exchange.DeclareOk,
  File "/Users/richmond/Projects/backend/env/lib/python3.6/site-packages/amqp/abstract_channel.py", line 64, in send_method
    conn.frame_writer(1, self.channel_id, sig, args, content)
  File "/Users/richmond/Projects/backend/env/lib/python3.6/site-packages/amqp/method_framing.py", line 174, in write_frame
    write(view[:offset])
  File "/Users/richmond/Projects/backend/env/lib/python3.6/site-packages/amqp/transport.py", line 269, in write
    self._write(s)
  File "/Users/richmond/Projects/backend/env/lib/python3.6/site-packages/eventlet/greenio/base.py", line 397, in sendall
    tail = self.send(data, flags)
  File "/Users/richmond/Projects/backend/env/lib/python3.6/site-packages/eventlet/greenio/base.py", line 391, in send
    return self._send_loop(self.fd.send, data, flags)
  File "/Users/richmond/Projects/backend/env/lib/python3.6/site-packages/eventlet/greenio/base.py", line 378, in _send_loop
    return send_method(data, *args)
BrokenPipeError: [Errno 32] Broken pipe
[2017-05-22 17:18:11,032: INFO/MainProcess] Connected to amqp://user123:**@192.168.99.100:5672//
[2017-05-22 17:18:11,046: INFO/MainProcess] mingle: searching for neighbors
[2017-05-22 17:18:12,075: INFO/MainProcess] mingle: all alone
[2017-05-22 17:18:12,104: INFO/MainProcess] [email protected] ready.

$ pip congelar

alabaster==0.7.10
alembic==0.9.1
amqp==2.1.4
aniso8601==1.2.0
appdirs==1.4.3
argh==0.26.2
Babel==2.4.0
billiard==3.5.0.2
blinker==1.4
bumpversion==0.5.3
cached-property==1.3.0
celery==4.0.2
cffi==1.10.0
click==6.7
colorama==0.3.8
coverage==4.1
cryptography==1.7
docker==2.2.1
docker-compose==1.11.2
docker-pycreds==0.2.1
dockerpty==0.4.1
docopt==0.6.2
docutils==0.13.1
ecdsa==0.13
enum-compat==0.0.2
eventlet==0.21.0
factory-boy==2.8.1
Faker==0.7.11
flake8==2.6.0
Flask==0.12
Flask-Babel==0.11.2
Flask-Cors==3.0.2
Flask-GraphQL==1.4.0
Flask-Mail==0.9.1
Flask-Migrate==2.0.3
Flask-RESTful==0.3.5
Flask-Script==2.0.5
Flask-SocketIO==2.8.6
Flask-SQLAlchemy==2.1
future==0.16.0
graphene==1.1.3
graphene-sqlalchemy==1.1.1
graphql-core==1.1
graphql-relay==0.4.5
greenlet==0.4.12
gunicorn==19.7.1
idna==2.5
imagesize==0.7.1
inflection==0.3.1
iso8601==0.1.11
itsdangerous==0.24
Jinja2==2.9.6
jsonschema==2.6.0
kombu==4.0.2
Mako==1.0.6
MarkupSafe==1.0
mccabe==0.5.3
mod-wsgi==4.5.15
ndg-httpsclient==0.4.2
packaging==16.8
pathtools==0.1.2
pluggy==0.3.1
promise==2.0
py==1.4.33
pyasn1==0.2.3
pycodestyle==2.0.0
pycparser==2.17
pycrypto==2.6.1
pyflakes==1.2.3
Pygments==2.2.0
PyMySQL==0.7.10
pyOpenSSL==17.0.0
pyparsing==2.2.0
python-dateutil==2.6.0
python-editor==1.0.3
python-engineio==1.4.0
python-jose==1.3.2
python-socketio==1.7.4
pytz==2017.2
PyYAML==3.11
raven==5.32.0
requests==2.11.1
singledispatch==3.4.0.3
six==1.10.0
snowballstemmer==1.2.1
Sphinx==1.4.8
SQLAlchemy==1.1.5
texttable==0.8.8
tox==2.3.1
typing==3.6.1
vine==1.1.3
virtualenv==15.1.0
voluptuous==0.9.3
watchdog==0.8.3
websocket-client==0.40.0
Werkzeug==0.12.1

Tengo el mismo problema y estoy usando las mismas versiones y no puedo encontrar una solución :(

Estoy usando kombu y me encuentro con la misma situación, no estoy seguro, pero creo que tal vez sea un problema trabajar con haproxy.

Cuando se conecta a haproxy, que enruta las conexiones a varios nodos de rabbitmq, tanto los productores como los consumidores tienen el mismo problema de "conexión con el intermediario perdido", pero cuando se conectan directamente a un nodo de rabbitmq, el problema nunca ocurre.

También viendo esto, y también detrás de haproxy:

kombu==4.0.2
celery==4.0.2
redis==2.10.5

Tal vez también haya sucedido con los corredores de SQS:

boto==2.47.0
celery==4.0.2
kombu==4.0.2

El mismo problema aquí, Celery con RabbitMQ y eventlet.

amqp == 2.2.1
billar == 3.5.0.3
apio == 4.1.0
Django == 1.8.5
eventlet == 0.21.0
kombu == 4.1.0
pytz == 2017.2
vid == 1.1.4

[2017-08-10 06:35:39,629: WARNING/MainProcess] consumer: Connection to broker lost. Trying to re-establish the connection...
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/celery/worker/consumer/consumer.py", line 320, in start
    blueprint.start(self)
  File "/usr/lib/python2.7/site-packages/celery/bootsteps.py", line 119, in start
    step.start(parent)
  File "/usr/lib/python2.7/site-packages/celery/worker/consumer/consumer.py", line 596, in start
    c.loop(*c.loop_args())
  File "/usr/lib/python2.7/site-packages/celery/worker/loops.py", line 118, in synloop
    connection.drain_events(timeout=2.0)
  File "/usr/lib/python2.7/site-packages/kombu/connection.py", line 301, in drain_events
    return self.transport.drain_events(self.connection, **kwargs)
  File "/usr/lib/python2.7/site-packages/kombu/transport/pyamqp.py", line 103, in drain_events
    return connection.drain_events(**kwargs)
  File "/usr/lib/python2.7/site-packages/amqp/connection.py", line 485, in drain_events
    while not self.blocking_read(timeout):
  File "/usr/lib/python2.7/site-packages/amqp/connection.py", line 490, in blocking_read
    frame = self.transport.read_frame()
  File "/usr/lib/python2.7/site-packages/amqp/transport.py", line 240, in read_frame
    frame_header = read(7, True)
  File "/usr/lib/python2.7/site-packages/amqp/transport.py", line 415, in _read
    s = recv(n - len(rbuf))
  File "/usr/lib/python2.7/site-packages/eventlet/greenio/base.py", line 360, in recv
    return self._recv_loop(self.fd.recv, b'', bufsize, flags)
  File "/usr/lib/python2.7/site-packages/eventlet/greenio/base.py", line 354, in _recv_loop
    self._read_trampoline()
  File "/usr/lib/python2.7/site-packages/eventlet/greenio/base.py", line 325, in _read_trampoline
    timeout_exc=socket_timeout('timed out'))
  File "/usr/lib/python2.7/site-packages/eventlet/greenio/base.py", line 207, in _trampoline
    mark_as_closed=self._mark_as_closed)
  File "/usr/lib/python2.7/site-packages/eventlet/hubs/__init__.py", line 163, in trampoline
    return hub.switch()
  File "/usr/lib/python2.7/site-packages/eventlet/hubs/hub.py", line 295, in switch
    return self.greenlet.switch()
  File "/usr/lib/python2.7/site-packages/eventlet/hubs/hub.py", line 347, in run
    self.wait(sleep_time)
  File "/usr/lib/python2.7/site-packages/eventlet/hubs/poll.py", line 84, in wait
    presult = self.do_poll(seconds)
  File "/usr/lib/python2.7/site-packages/eventlet/hubs/epolls.py", line 61, in do_poll
    return self.poll.poll(seconds)
  File "/usr/lib/python2.7/site-packages/celery/apps/worker.py", line 333, in restart_worker_sig_handler
    safe_say('Restarting celery worker ({0})'.format(' '.join(sys.argv)))
  File "/usr/lib/python2.7/site-packages/celery/apps/worker.py", line 89, in safe_say
    print('\n{0}'.format(msg), file=sys.__stderr__)
IOError: [Errno 32] Broken pipe
[2017-08-10 06:35:39,820: INFO/MainProcess] Connected to amqp://guest:**@127.0.0.1:5672//
[2017-08-10 06:35:39,940: INFO/MainProcess] mingle: searching for neighbors
[2017-08-10 06:35:40,975: INFO/MainProcess] mingle: all alone
[2017-08-10 06:35:41,115: INFO/MainProcess] pidbox: Connected to amqp://guest:**@127.0.0.1:5672//.

Tengo el mismo problema con RabbitMQ ejecutándose en localhost. Es extraño que las conexiones locales se agoten o pierdan la conexión. Tengo algunas tareas bastante intensivas y mi CPU está al 100%, pero mi uso de memoria es bajo. ¿Causaría eso conexiones caídas?

celery==4.0.2
kombu==4.0.2
Django==1.8.6
RabbitMQ==3.2.4

@chrisspen , ¿

[2017-10-11 13:34:57,244: WARNING/MainProcess] consumer: Connection to broker lost. Trying to re-establish the connection...
Traceback (most recent call last):
  File "/usr/local/python/lib/python2.7/site-packages/celery/worker/consumer/consumer.py", line 318, in start
    blueprint.start(self)
  File "/usr/local/python/lib/python2.7/site-packages/celery/bootsteps.py", line 119, in start
    step.start(parent)
  File "/usr/local/python/lib/python2.7/site-packages/celery/worker/consumer/consumer.py", line 594, in start
    c.loop(*c.loop_args())
  File "/usr/local/python/lib/python2.7/site-packages/celery/worker/loops.py", line 88, in asynloop
    next(loop)
  File "/usr/local/python/lib/python2.7/site-packages/kombu/async/hub.py", line 345, in create_loop
    cb(*cbargs)
  File "/usr/local/python/lib/python2.7/site-packages/kombu/transport/redis.py", line 1039, in on_readable
    self.cycle.on_readable(fileno)
  File "/usr/local/python/lib/python2.7/site-packages/kombu/transport/redis.py", line 337, in on_readable
    chan.handlers[type]()
  File "/usr/local/python/lib/python2.7/site-packages/kombu/transport/redis.py", line 714, in _brpop_read
    **options)
  File "/usr/local/python/lib/python2.7/site-packages/redis/client.py", line 585, in parse_response
    response = connection.read_response()
  File "/usr/local/python/lib/python2.7/site-packages/redis/connection.py", line 577, in read_response
    response = self._parser.read_response()
  File "/usr/local/python/lib/python2.7/site-packages/redis/connection.py", line 238, in read_response
    response = self._buffer.readline()
  File "/usr/local/python/lib/python2.7/site-packages/redis/connection.py", line 168, in readline
    self._read_from_socket()
  File "/usr/local/python/lib/python2.7/site-packages/redis/connection.py", line 143, in _read_from_socket
    (e.args,))
ConnectionError: Error while reading from socket: ('Connection closed by server.',)

También tuve una "Conexión con el corredor perdida" usando conejo + apio con un uso elevado de CPU; no estoy seguro está relacionado.

esto podría ser un problema con HAProxy

@auvipy lo dudo. No uso HAProxy y he estado intentando usar Celery 4.0.3 para migrar desde 3.1.25.

Sigo recibiendo este error.

Esperemos el lanzamiento de 4.2

Tengo el mismo problema con Redis ejecutándose en localhost. Mi valor de tiempo de espera de configuración de redis es 5 . Cuando se ejecutan demasiadas tareas más allá de los 5 segundos, resultaría en esta excepción:

[2018-03-28 10:13:09,557: WARNING/MainProcess] consumer: Connection to broker lost. Trying to re-establish the connection...
Traceback (most recent call last):
  File "/usr/local/python2.7/lib/python2.7/site-packages/celery-4.2.0rc1-py2.7.egg/celery/worker/consumer/consumer.py", line 322, in start
    blueprint.start(self)
  File "/usr/local/python2.7/lib/python2.7/site-packages/celery-4.2.0rc1-py2.7.egg/celery/bootsteps.py", line 119, in start
    step.start(parent)
  File "/usr/local/python2.7/lib/python2.7/site-packages/celery-4.2.0rc1-py2.7.egg/celery/worker/consumer/consumer.py", line 598, in start
    c.loop(*c.loop_args())
  File "/usr/local/python2.7/lib/python2.7/site-packages/celery-4.2.0rc1-py2.7.egg/celery/worker/loops.py", line 91, in asynloop
    next(loop)
  File "/usr/local/python2.7/lib/python2.7/site-packages/kombu/async/hub.py", line 354, in create_loop
    cb(*cbargs)
  File "/usr/local/python2.7/lib/python2.7/site-packages/kombu/transport/redis.py", line 1040, in on_readable
    self.cycle.on_readable(fileno)
  File "/usr/local/python2.7/lib/python2.7/site-packages/kombu/transport/redis.py", line 337, in on_readable
    chan.handlers[type]()
  File "/usr/local/python2.7/lib/python2.7/site-packages/kombu/transport/redis.py", line 714, in _brpop_read
    **options)
  File "/usr/local/python2.7/lib/python2.7/site-packages/redis/client.py", line 680, in parse_response
    response = connection.read_response()
  File "/usr/local/python2.7/lib/python2.7/site-packages/redis/connection.py", line 624, in read_response
    response = self._parser.read_response()
  File "/usr/local/python2.7/lib/python2.7/site-packages/redis/connection.py", line 284, in read_response
    response = self._buffer.readline()
  File "/usr/local/python2.7/lib/python2.7/site-packages/redis/connection.py", line 216, in readline
    self._read_from_socket()
  File "/usr/local/python2.7/lib/python2.7/site-packages/redis/connection.py", line 191, in _read_from_socket
    (e.args,))
ConnectionError: Error while reading from socket: ('Connection closed by server.',)
[2018-03-28 10:13:09,558: WARNING/MainProcess] Restoring 7 unacknowledged message(s)

Y descubrí que si el argumento para la aplicación de apio es demasiado largo, como una cadena de 65000 de longitud, y la conexión entre apio y redis está cerrada y no se puede volver a conectar.
Aquí está el ejemplo:

# filename: task.py
# test for celery task
import time
from celery import Celery
app = Celery('tasks', broker='redis://:@127.0.0.1:6379/2')

@app.task
def test(data):
    time.sleep(20)

iniciar 2 apio trabajador

celery -A task worker -c 2 -l info 

# filename: test.py
# produce celery task 
from mytask import test
for i in range(40):
    test.delay('1'*65000)
 ```
run  test 
```bash
python test.py

Espere unos 2 minutos, luego ejecute este comando y no encontrará ninguna conexión entre apio y redis ESTABLECIDA.

netstat -natp | grep 6379 | grep ESTABLISHED

Indicó que las conexiones entre apio y redis se cerraron y se volvieron a conectar fallaron. Entonces, ¿qué causa las conexiones caídas y la reconexión falla?

celery-4.1.0 or celery-4.2.0rc1
kombu==4.1.0
billiard==3.5.0.3
pytz==2018.3
amqp==2.2.2
vine==1.1.4

redis 4.0.2

No sé por qué sucedió esto, pero si el tiempo de espera de redis.conf se establece en 0, los problemas desaparecerán.
Gracias.

Tengo el mismo problema con amqp broker y:
kombu == 4.2.1
apio == 4.2.0

El mismo problema con apio == 4.2.0 y kombu == 4.2.1

alguien tuvo alguna solución en la práctica?

El mismo problema con el apio == 4.2.1
Cómo resuelvo esto ?

mismo problema, estoy usando celery == 4.2.0, kombu == 4.2.0 y Rabbitmq cluster como corredor
alguna solución ?

También tengo este problema. Mis registros reciben spam constantemente debido a estas excepciones.

Lo mismo ocurre con el último apio, ¿alguna solución disponible?

Intento seguir para suprimir los registros. Me funciona bien.

• SQS con botocore
• Vuelva a intentarlo cuando haya error de conexión

from billiard.exceptions import (
    SoftTimeLimitExceeded as CelerySoftTimeLimitExceeded,
)
from botocore.exceptions import (
    ClientError as BotocoreClientError,
    HTTPClientError as BotocoreHTTPClientError,
)

@app.task(
    autoretry_for=(
        BotocoreClientError,
        BotocoreHTTPClientError,
        CelerySoftTimeLimitExceeded,
    ),
)
def my_task():
    pass

Hola.
Tengo el mismo problema cuando uso la versión del paquete celery 4.2.1 y amqp 2.4.0.
ahora pruebo apio 4.2.1 y amqp 2.3.2, parece bueno.
trabajar bien.
La esperanza puede ayudar a alguien que tiene el problema.

@auvipy , puedo ver que este problema se cerró, pero no estoy seguro de si hay una solución para él todavía o si hay una planeada ... Sería genial si pudiera confirmar cuál es el estado actual, gracias.

¿Podrías probar con apio y kombu del maestro e informar de nuevo?

También tengo este problema. Probé la solución de

Mismo problema,
apio 4.2.1
kombu 4.3.0
amqp 2.4.1
redis 2.10.5

Se corrigió al degradar a amqp 2.3.2 según la respuesta de @shaoeChen .

En el caso especial del clúster AWS ELB + de Rabbit MQ, esta configuración parece solucionarlo:

El tiempo de espera inactivo predeterminado es 60.

Mismo problema

redis == 3.2.1
apio [redis] == 4.3.0

Reiniciar el apio estará bien

prueba el apio == 4.4.0rc5

@auvipy sería bueno si hace referencia al cambio en celery==4.4.0rc5 que soluciona este problema para la posteridad.

FWIW, subir a 4.4.0rc5 parece haber estabilizado este problema para mí también.

apio == 4.4.0 es la versión estable actual. intente eso e informe de nuevo.

celery==4.4.0
kombu==4.6.7
funciona (mejor).

Gracias por hacer referencia al hito de 4.4.x

ACTUALIZACIÓN: Mientras que antes, desconectaba conexiones con frecuencia (aproximadamente cada minuto) ... ¿ahora parece estar desconectando conexiones con mucha menos frecuencia (una vez por hora)? Tendría que registrarlo y hacer un análisis de registro más profundo para obtener una señal más clara.

Estoy enfrentando el mismo problema
[2020-04-22 05:31:09,243: WARNING/MainProcess] consumer: Connection to broker lost. Trying to re-establish the connection... Traceback (most recent call last): File "c:\users\administrator\code\user\cel_env\lib\site-packages\redis\connection.py", line 700, in send_packed_command sendall(self._sock, item) File "c:\users\administrator\code\user\cel_env\lib\site-packages\redis\_compat.py", line 8, in sendall return sock.sendall(*args, **kwargs) File "c:\users\administrator\code\user\cel_env\lib\site-packages\eventlet\greenio\base.py", line 403, in sendall tail = self.send(data, flags) File "c:\users\administrator\code\user\cel_env\lib\site-packages\eventlet\greenio\base.py", line 397, in send return self._send_loop(self.fd.send, data, flags) File "c:\users\administrator\code\user\cel_env\lib\site-packages\eventlet\greenio\base.py", line 384, in _send_loop return send_method(data, *args) ConnectionResetError: An existing connection was forcibly closed by the remote host

mi lista de pips
billiard==3.6.3.0 BTrees==4.4.1 celery==4.4.2 kombu==4.6.8 redis==3.4.1

Estoy enfrentando el mismo problema que se informó en https://github.com/apache/airflow/issues/11622. Esto comenzó a ocurrir después de https://github.com/apache/airflow/pull/11336

Lo interesante es que sucede solo cuando intentamos ejecutar Celery worker de manera demonizada.

celery==4.4.7
kombu==4.6.11
billiard==3.6.3.0
redis==3.5.3

FYI: Intenté actualizar a 5.0 pero no tuve éxito.

Tuve un problema similar al usar el HAproxy proporcionado por redis-ha Helm chart . Resulta que su timeout client predeterminado era 30s , y el intervalo de mantenimiento de TCP predeterminado de Redis es " aproximadamente 5 minutos ". Elevando timeout client y timeout server ambos a 330s , el problema parece haberse solucionado.

Tuve un problema similar al usar el HAproxy proporcionado por redis-ha Helm chart . Resulta que su timeout client predeterminado era 30s , y el intervalo de mantenimiento de TCP predeterminado de Redis es " aproximadamente 5 minutos ". Elevando timeout client y timeout server ambos a 330s , el problema parece haberse solucionado.

¿Deberíamos proporcionar esto en los documentos?

Bueno, no estoy seguro de si es la solución correcta, pero cambié mi instancia EC2 en Amazon en la que utilizo celery + rabbitmq + gunicorn + supervisor como parte de mi infraestructura de tareas largas (de hasta varias horas) con miles de mensajes gestionados por este 24/7 ...

... - desde 1 Gb de tamaño de memoria hasta 2 Gb (tal vez tenga diferentes necesidades, así que ajuste en consecuencia)

Como mostró el archivo syslog en Ubuntu, el error de oom estaba matando a los corredores y otras cosas, y el aumento del tamaño de la memoria del servidor ayudó a resolver esto.

Ahora mis registros están libres de errores.
Y no es necesario ajustar mi código.

Bueno, no estoy seguro de si es la solución correcta, pero cambié mi instancia EC2 en Amazon en la que utilizo celery + rabbitmq + gunicorn + supervisor como parte de mi infraestructura de tareas largas (de hasta varias horas) con miles de mensajes gestionados por este 24/7 ...

... - desde 1 Gb de tamaño de memoria hasta 2 Gb (tal vez tenga diferentes necesidades, así que ajuste en consecuencia)

Como mostró el archivo syslog en Ubuntu, el error de oom estaba matando a los corredores y otras cosas, y el aumento del tamaño de la memoria del servidor ayudó a resolver esto.

Ahora mis registros están libres de errores.
Y no es necesario ajustar mi código.

¡muy practico!