Всем привет.

Боремся тут с Celery несколько месяцев, никак не можем понять в чем причина.

Стек такой: Python 3.7, Celery 4.4.2, очередь хранится в Redis 5 (редис крутится в контейнере вместе с другими воркерами), все крутится в Докер контейнерах (сейчас около 40-50 штук) в Swarm mode на 4х серверах по 4 Гб RAM, хостимся на DigitalOcean.

Основная проблема - иногда воркеры перестают брать задачи из очереди. На некоторых воркерах такое частенько происходит, на некоторые иногда, не некоторых никогда. В результате очередь переполняется и в редисе кончается оперативка.

Бывает, что редису не удается сделать bgsave, он становится недоступным, из-за этого воркеры теряют коннекшн и больше не пытаются к нему подключиться.

Бывает, что воркер вроде бы работает, но такое чувство что в пол силы - после рестарта воркеры по ощущениям начинают генерить в 2 раза больше логов.

В общем, искать причину почему отваливаются воркеры непонятно как, поэтому решили пойти по другому пути: воткнули на все контейнеры хелсчек через celery ping каждые 15 секунд (на каждом из 40 воркеров). Но и тут засада - воркер может работать, и не отвечать на пинг, и наоборот. А еще после включения таких хелсчеков редис стал постоянно ребутится.

В общем, сейчас хочется:
- разобраться в первопричине, почему воркеры перестают брать задачи
- сделать хелсчеки, чтобы система сама восстанавливалась в случае, если воркер перестает брать задачи. ну или как минимум оповещала нас об этом.
- минимизировать падения редиса, а в случае если это все-таки происходит - чтобы выполнения задач не останавливалось (вводить дополнительную ноду?)

у кого есть какие дельные советы - буду признателен, если поделитесь 🙂

https://www.youtube.com/watch?v=MwI4qp3ykAc Там вроде во второй половине доклада было про возможные проблемы.

У нас тоже есть подобная проблема с тем, что воркер как будто работает, а на самом деле задачи не берёт.
Пришли к выводу, что связано с нехваткой памяти. Соседний процесс иногда её отжирает и один-два воркера повисают.
Боремся мониторингом задач в очереди. В критичное время, вроде НГ, просто докидываем железа и всё работает.

Тут вроде бы тоже было полно советов https://www.youtube.com/watch?v=j471a3JLeA0

Самый правильный способ решить эту проблему, как я понял — выкинуть целери. Любые другие решения либо не работают, либо доставляют боль и тоже не работают.

Всё ровно так.

“Give a man a program, frustrate him for a day.
Teach a man to program, frustrate him for a lifetime.” 😊

а пароль через керберос в АД через питон не приходилось менять никому? как понимаю мы вот это используем https://github.com/geertj/python-ad/blob/master/lib/ad/protocol/krb5.c

change_password выдает ошибку с нечитаемой хренью и не понимаю как это интепритировать

40 контейнеров и вы очередь держите в Redis? Да вы смелые однако. У нас очередь в RabbitMQ при только 3-ех бекендах которые генерят задачки. Rabbit хоят бы нормально умеет персистить очередь и упирается в основном в место на диске. 15 млн. задач в очереди как нехрен делать 😊

По поводу памяти - в celery есть настройка что бы делать рестарт дочернему процессу, если он стал занимать много памяти (конечно же после того как он завершит обработку задачи).

Конкретно такой проблемы с залипонами я у нас не помню (8 лет уже на этом celery продакшены пилим).
Разве что там такая фишка была раньше (может только для Rabbit актуальная) - celery-мастер может из очереди сразу доставать таски пачками (так быстрее в плане сети). Но потом была жопа - пока вся эта пачка не будет обработана, следующие таски celery не выгребал. В результате если одна таска залипала надолго, то все остальные процессы простаивали в холостую. Мы просто через настройки отключили такой batch-инг. У нас не настолько быстро прилетают и обрабатываются таски, что бы "оверхед по сети" как-то влиял.

А как в Redis работает поздний acknowledged, когда сообщение из очереди удаляется только после того как воркер корректно обработает задачу? И при этом это сообщение не "захавает" другой воркер. Мне было бы сыкотно без этой фичи - воркер упал и таску потерял, ищи потом ветра в поле.

ну у нас уже есть подозрения, что он не справляется.

и если честно, у редиса есть еще одна серьезная трабла, которую до сих пор не удалось побороть - он таски может дублировать, которые с eta/countdown. приходится колхозить всякие доп.проверки

но на рэббит съезжать все не хочется, потому что с ним особо опыта нет

а редис все равно нужен будет

Я всегда говорил, что редис в качестве очереди подходит только для Pet-проектов или для совсем не важных мелких продакшенов