Live data from Hacker News

Celery in production: Three more years of fixing bugs

ayushshanker.com

11–20 of 63 posts

Re: Celery in production: Three more years of fixing bugs

#11
post #3

I ran Celery in many projects in production over the past 10 years; I would not recommend it. It is mostly a constant fight even though it is the first thing most people grab when they have a Django stack.

man... couldnt agree more.

Re: Celery in production: Three more years of fixing bugs

#14
post #2

> Supervisor should've killed celery's forked workers once the parent dies. Either it is not reliable or we haven't been able to make this happen in at least a few attempts now. Use systemd instead of supervisord for misbehaving forking daemons like this. If you set "KillMode=mixed" you get a nice compromise between "signal the parent and give things a configurable grace period to shut themselves down" and "zero risk…

I find supervisor's event listener functionality useful for implementing watchdog processes. I have the supervised process write an event whenever it successfully completes a task. Meanwhile, a separate event listener process has a watchdog timer which asks supervisor to restart the supervised process if it hasn't checked in recently enough.

Does systemd have anything like supervisor events?

http://supervisord.org/events.html#events

Re: Celery in production: Three more years of fixing bugs

#15
post #3

I ran Celery in many projects in production over the past 10 years; I would not recommend it. It is mostly a constant fight even though it is the first thing most people grab when they have a Django stack.

I've been running four separate installs of Celery since 2014 or so processing about 10-20 million jobs a day, using reddit as a broker, and with about 100 worker instances per install. It just works, but I don't use Celery results or any esoteric features.

Re: Celery in production: Three more years of fixing bugs

#17
post #15
post #3

I ran Celery in many projects in production over the past 10 years; I would not recommend it. It is mostly a constant fight even though it is the first thing most people grab when they have a Django stack.

I've been running four separate installs of Celery since 2014 or so processing about 10-20 million jobs a day, using reddit as a broker, and with about 100 worker instances per install. It just works, but I don't use Celery results or any esoteric features.

Reddit :)

Re: Celery in production: Three more years of fixing bugs

#18
post #3

I ran Celery in many projects in production over the past 10 years; I would not recommend it. It is mostly a constant fight even though it is the first thing most people grab when they have a Django stack.

What would you recommend instead?

I'm also in the 'anything but Celery' camp:

https://dramatiq.io/motivation.html

If you're backing onto something like SQS or Rabbit (Redis is a bit trickier), it's not the worst thing to hand-roll either. Then you understand exactly what trade-offs you're making.

Re: Celery in production: Three more years of fixing bugs

#20
post #14
post #2

> Supervisor should've killed celery's forked workers once the parent dies. Either it is not reliable or we haven't been able to make this happen in at least a few attempts now. Use systemd instead of supervisord for misbehaving forking daemons like this. If you set "KillMode=mixed" you get a nice compromise between "signal the parent and give things a configurable grace period to shut themselves down" and "zero risk…

I find supervisor's event listener functionality useful for implementing watchdog processes. I have the supervised process write an event whenever it successfully completes a task. Meanwhile, a separate event listener process has a watchdog timer which asks supervisor to restart the supervised process if it hasn't checked in recently enough. Does systemd have anything like supervisor events? http://supervisord.org/ev…

Yes, sd_notify(0, "WATCHDOG=1") should get you started.
Post reply on HN