Средний

8 мин

5.5K

Вступление и заметка об автоскейлинге

В прошлой статье я допустил неточность, сказав, что prefork это один из пулов, к которому применим autoscale. Точнее было бы сказать, что prefork — единственный пул c которым есть смысл использовать автомасштабирование Celery. Сами авторы Eventlet не скупятся на зеленые потоки и по умолчанию создают 1000 потоков.

Механизм autoscale технически реализован и для Eventlet, и для Gevent, но на практике бесполезен: в отличие от процессов и системных потоков(threading) новые гринлеты почти не увеличивают нагрузку на систему. Не нужно переключать контекст, мигрировать по ядрам и вставать в очередь к планировщику. Не вытесняющая, а кооперативная многозадачность: зеленые потоки добровольно уступают контроль в точках, где происходит операция ввода-вывода (I/O). Конечно, есть и обратная сторона медали: если один из потоков не в состоянии уступить ресурс, то это может привести к остановке всего воркера.

Примечание: Далее слова гринлет, поток, зелёный поток будут использоваться как синонимы. Если понятие будет касаться ОС, то к нему будет добавлено системный.

Gevent vs. Eventlet

Важное примечание

Согласно официальной документации Eventlet, разработка новых проектов на Eventlet не рекомендуется. Проект сейчас находится в режиме поддержки и исправления ошибок. Для новых приложений авторы советуют использовать, а старым проектам — мигрировать на asyncio. В контексте же Celery можно мигрировать на Gevent.

* - количество звёздочек актуально на май 2026 года.

Основное различие между двумя библиотеками кроется в их внутреннем планировщике (event loop) и реализации. Отсюда же и разница в производительности, патчинге и совместимости.

Hub’s

Хаб (Hub) — это центральный планировщик, который реализует событийный цикл (event loop). Он занимается мониторингом I/O-операций, управляет таймерами и диспетчеризирует события нужным обработчикам.

У Eventlet есть четыре реализации хаба, которые выбираются автоматически в порядке epoll → poll → select. Хаб выбирается в зависимости от системы(см. таблицу), но вы можете выбрать хаб вручную, в том числе и AsyncioHub, который здесь рассматривать не будет, так как асинхронность редко используется внутри Celery-задач. Главная причина для выбора конкретного хаба — это оптимизация производительности под платформу и нагрузку.

У Gevent же внутренний хаб и цикл событий скрыты от пользователя и не предназначены для прямого выбора или настройки. Хаб создаётся автоматически для каждого потока и предоставляет к нему доступ через API, но смена реализации не является публичным интерфейсом.

• libev — легковесный event loop на C, используемый по умолчанию. Обеспечивает высокую производительность на Linux через epoll, на macOS — через kqueue.

• libuv — движок из Node.js, доступен как альтернатива. Лучше работает в Windows.

Monkey Patching

Gevent и Eventlet на лету заменяют блокирующие функции стандартной библиотеки Python (например, socket.recv, time.sleep, requests.get) на их неблокирующие версии, интегрированные с event loop. Даже несмотря на то, что Celery сам старается патчить, когда вы запускаете воркер с гринлет-пулом, всё же лучше вызывать патчинг явно в собственном коде до импорта celery и других модулей.

from gevent import monkey
monkey.patch_all()

from celery import Celery
app = Celery('proj')

Как это выглядит изнутри воркера Celery:

1. Когда зеленый поток выполняет операцию чтения данных из сокета, которая обычно заморозила бы его в ожидании, хаб зеленых потоков перехватывает этот запрос через monkey-patched функцию.

2. Блокирующий вызов преобразуется в регистрацию события. Поток сообщает event loop’у: «Я жду, пока появятся данные на этом сокете». После этого он немедленно уступает управление.

3. Воркер Celery переключается на выполнение другого зеленого потока, который готов к работе.

4. Когда данные приходят, event loop просыпается, находит ожидающий поток и дает ему возможность продолжить выполнение.

Совместимость стандартных модулей с Monkey Patching

Список пропатченных библиотек можно проверить

from gevent import monkey
print(monkey.get_patched_modules())

import eventlet.patcher
print(eventlet.patcher.is_monkey_patched('socket'))

Таким образом этот пул Celery позволяет одному воркеру с одним системным процессом поддерживать тысячи одновременно ожидающих I/O зеленых потоков при минимальном потреблении ресурсов. Один автор утверждает, что сократил потребление памяти на 63%.

Обратная сторона медали

1. Ограничения на библиотеки или дополнительные патчи. См. таблицу выше.

2. Воркеры нужно запускать с флагами, которые отключат блокирующие цикл событий инструменты Celery.

   • --without-gossip отключает обмен событиями между воркерами о состоянии кластера. Использовать: в больших кластерах, чтобы снизить нагрузку на брокер

   • --without-mingle отключает синхронизацию между воркерами на старте. Использовать: при частых перезапусках воркеров, чтобы ускорить старт.

   • --without-heartbeat отключает «общение» между воркером и брокером о статусе исполнителя. Использовать: только если вы уверены в стабильности сети (рискуете потерять контроль над «зависшими» воркерами).

3. Отсутствие штатных средств Celery по контролю работы воркера(лимиты по времени, счёт выполненных задач).

4. Патчинг сам по себе. Стоит создать новую задачу с ошибкой и можно навредить всему воркеру. Просто мнение.

Runtime

Рабочее окружение

Все замеры проведены с версией celery 5.6.3, на ноутбуке с процессором AMD Ryzen 5 5500U with Radeon Graphics × 6 в консоли Linux Mint 22.3 - Cinnamon 64-bit.

С помощью cgroups и cpuset ограничил эксперимент двумя ядрами(первые потоки): 5 и 6. Некая имитация отдельного 2-ядерного сервера.

Брокер: RabbitMQ. Для некоторых брокеров, к примеру, старых версий Redis механизм получения задач может работать иначе.

Методика

Каждые 1.6(5 — по расписанию) секунд в брокере публикуются задачи(I/O и memory-bound, нормальный runtime — 1.7 сек) в количестве, равном максимальному количеству рабочих потоков. Каждый рабочий поток ограничен worker_prefetch_multiplier=1, то есть может взять одну задачу за раз. Длительность одного замера 300 секунд, по окончании работы воркер перезапускается, а очередь опустошается. Каждый вариант(2 очереди Х 2 режима Х 3 кол-ва потоков) запускается 20 раз.

Все 240 замеров были проведены в случайном порядке.

Прошу учесть, что в проведённом эксперименте задачи содержали существенную для гринлетов (35% времени от нормального runtime) CPU‑нагрузку. В таких условиях зелёные потоки уступают prefork-воркерам, которые используют оба ядра(процессы распределяет планировщик ОС). В чисто I/O-сценариях(5-10% времени CPU) отрыв был бы меньше или gevent мог бы оказаться быстрее.

Накопительная нагрузка (cumulative)

Равномерная нагрузка по расписанию (schedule)

Как видно, Gevent и Eventlet при такой нагрузке друг от друга мало чем отличаются. С натяжкой можно сказать, что gevent начинает формировать базу для превосходства над eventlet при тысячах потоков, но подобная экстраполяция будет преждевременной.

Для задач по расписанию есть интересная деталь, их количество не кратно 120, что было нормой для prefork. Скорее всего это связано с тем, что в последней итерации воркер иногда не успевал доделать задачу и она «испарялась»: при остановке воркера невыполненная задача возвращалась в очередь и там уже удалялась перед новым запуском. И поэтому снова подтверждается тезис о том, что если у вас много вычислений внутри задачи, используйте prefork.

Гринлеты vs. Prefork

Пересчитаем на одно ядро. Возьмём нагруженную очередь (cumulative), режим 8 потоков/процессов:

Как видно, даже на одно ядро prefork производительнее (~17%) для конкретной синтетической задачи. Latency у gevent в 4.4 раза выше (98.7 с против 22.6 с), что также ожидаемо: очередь накапливается, потому что одно ядро не справляется. Но всё-таки не ставьте крест на зелёных потоках! Они не предназначены для длительной и серьёзной нагрузки на процессор.

Малые выводы

1. Выбирайте gevent для celery в новых проектах. Eventlet официально не рекомендуется.

2. Если в задаче больше 10-15% чистого CPU, стоит рассматривать prefork. Уже при 35% CPU-времени prefork ощутимо выигрывает.

3. Зелёные потоки хороши для I/O-bound задач. Тысячи параллельных запросов к АПИ или БД, а потребление ресурсов на уровне одного системного процесса.

4. Блокировка event loop: если гринлет забывает уступить управление (цикл без sleep или I/O или высокая ЦПУ-нагрузка), он может заблокировать весь воркер.

5. Celery-time_limit и max_tasks_per_child не работают. Штатными средствами задачу прервать не удастся. Нужно настраивать тайм-ауты внутри задачи gevent.Timeout / eventlet.Timeout.

Я признаю ограничения эксперимента: заставил зеленые потоки трудиться над непривычными задачами. Поэтому постараюсь по окончании разбора Celery сделать большое сравнение пулов с реальными подключениями к БД, АПИ и какой-нибудь логикой.

Исходный код эксперимента: https://github.com/okolobackend/Celery-Architecture-and-Scaling