Зеленые потоки Celery. Gevent и Eventlet

okolobackend50 минут назад

Зеленые потоки Celery. Gevent и Eventlet

Уровень сложностиСреднийВремя на прочтение8 минОхват и читатели38Программирование*Python*Вступление и заметка об автоскейлинге

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

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

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

Gevent vs. Eventlet

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

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

GeventEventletРеализацияlibev / libuv (написаны на C)Чистый PythonПроизводительностьОжидается выше из-за C для 10k+ потоковМедленнее при очень высоких нагрузкахHub(координация гринлетов)Скрыт от пользователяМожно переключить (eventlet.hubs.use_hub())Monkey patchАгрессивный, но более гибкийКонсервативныйСтатус*Де-факто стандарт(6.4k stars)Только поддержка(1.3k stars).СтабильностьРеже встречаются критические сбоиБывают проблемы с соединениями БД и брокеров* - количество звёздочек актуально на май 2026 года.

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

Hub’s

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

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

ХарактеристикаSelectHubPollHubEpollHubAsyncioHubКроссплатформенностьДаТолько UnixТолько LinuxДаСистемный вызовselect.select()select.poll()select.epoll()Цикл событий Python asyncioПроизводительностьНаименьшаяХорошаяОтличная (сложность O(1))Хорошая, на уровне asyncioМакс. кол-во FDНизкое (обычно 1024)Высокое (зависит от системы)Очень высокое (зависит от системы)Зависит от платформыUse-caseПростые приложения, WindowsСерверы с умеренной нагрузкойВысоконагруженные серверы на LinuxИнтеграция или миграция на asyncioВыбор по умолчанию3-й приоритет (fallback)2-й приоритет1-й приоритет (если Linux)Только при явном указанииУ 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:

• Когда зеленый поток выполняет операцию чтения данных из сокета, которая обычно заморозила бы его в ожидании, хаб зеленых потоков перехватывает этот запрос через monkey-patched функцию.
• Блокирующий вызов преобразуется в регистрацию события. Поток сообщает event loop’у: «Я жду, пока появятся данные на этом сокете». После этого он немедленно уступает управление.
• Воркер Celery переключается на выполнение другого зеленого потока, который готов к работе.
• Когда данные приходят, event loop просыпается, находит ожидающий поток и дает ему возможность продолжить выполнение.

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

МодульGeventEventletПримечанияsocket✅ Полная✅ ПолнаяБазовый модуль, патчится в первую очередьssl✅ Полная✅ ПолнаяТребует monkey.patch_all() до импорта ssltime✅ sleep()✅ sleep()Только функции ожидания, не time.time()select / poll / epoll✅ Полная✅ ПолнаяКритично для event loopthreading⚠️ С флагом thread=True⚠️ С флагом thread=TrueПатчинг потоков — источник тонких багов, используйте с осторожностьюsubprocess⚠️ Частичная⚠️ ЧастичнаяPopen.wait() может блокировать, лучше выносить в threadpoolos⚠️ Только os.fork⚠️ МинимальноБольшинство системных вызовов остаются блокирующимиurllib / urllib2✅ Полная✅ ПолнаяУстаревшие модули, но работаютhttp.client / httplib✅ Полная✅ ПолнаяОснова для requests и других HTTP-клиентовqueue / Queue✅ Полная✅ ПолнаяЗамена на кооперативные очередиsignal⚠️ Ограниченная❌ Не поддерживаетсяОбработка сигналов в асинхронной модели — сложная темаdns / socket.getaddrinfo✅ С dns=True✅ ПолнаяВажно для асинхронных DNS-запросовpsycopg2✅ С psycogreen✅ С psycogreenТребуется отдельный патч: from psycogreen.gevent import patch_psycopgpymongo✅ Встроенная поддержка✅ Встроенная поддержкаБиблиотека сама детектит gevent/eventletredis-py✅ С gevent✅ С eventletРаботает «из коробки» при патчинге socketrequests⚠️ Работает, но не идеально⚠️ Работает, но не идеальноЛучше использовать grequests (gevent) или перейти на aiohttp + asyncioboto3 (AWS SDK)⚠️ Требует gevent.threadpool⚠️ Требует eventlet.tpoolМногие низкоуровневые вызовы блокирующиеcryptography / pyOpenSSL❌ Блокирует event loop❌ Блокирует event loopВыносите криптооперации в ThreadPoolnumpy / scipy❌ Блокирует event loop❌ Блокирует event loopТяжёлые CPU-вычисления останавливают весь воркерСписок пропатченных библиотек можно проверить

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

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

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

• Ограничения на библиотеки или дополнительные патчи. См. таблицу выше.
• Воркеры нужно запускать с флагами, которые отключат блокирующие цикл событий инструменты Celery.

• --without-gossip отключает обмен событиями между воркерами о состоянии кластера. Использовать: в больших кластерах, чтобы снизить нагрузку на брокер
• --without-mingle отключает синхронизацию между воркерами на старте. Использовать: при частых перезапусках воркеров, чтобы ускорить старт.
• --without-heartbeat отключает «общение» между воркером и брокером о статусе исполнителя. Использовать: только если вы уверены в стабильности сети (рискуете потерять контроль над «зависшими» воркерами).
• Отсутствие штатных средств Celery по контролю работы воркера(лимиты по времени, счёт выполненных задач).
• Патчинг сам по себе. Стоит создать новую задачу с ошибкой и можно навредить всему воркеру. Просто мнение.

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)

РежимСр. процессовДлительность (с)ЗадачThroughput (з/с)Сред. latency (с)CV latency95% ДИ для среднегоМедиана (с)90-й перц. (с)95-й перц. (с)gevent(2)1.00303.92224.40.7462.201.4%[61.80 – 62.60]61.83110.98116.60eventlet(2)1.00303.92224.30.7462.070.2%[62.00 – 62.14]61.43111.15115.80gevent(4)1.00304.06406.91.3471.200.5%[71.02 – 71.38]71.14125.94132.91eventlet(4)1.00304.06405.41.3371.530.6%[71.32 – 71.74]71.30126.44133.24gevent(8)1.00302.73544.21.8098.680.7%[98.37 – 98.98]98.02175.00184.68eventlet(8)1.00302.72542.51.7998.960.3%[98.82 – 99.11]98.55175.46185.12

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

РежимСр. процессовДлительность (с)ЗадачThroughput (з/с)Сред. latency (с)CV latency95% ДИ для среднегоМедиана (с)90-й перц. (с)95-й перц. (с)gevent(2)1.00302.73119.90.402.040.5%[2.04 – 2.05]2.142.412.43eventlet(2)1.00302.73119.90.402.040.4%[2.04 – 2.05]2.182.412.43gevent(4)1.00302.78238.10.792.560.5%[2.56 – 2.57]2.823.183.74eventlet(4)1.00302.78238.60.792.570.5%[2.56 – 2.57]2.793.193.74gevent(8)1.00302.88476.21.574.071.6%[4.04 – 4.10]3.756.457.08eventlet(8)1.00302.88476.51.574.092.1%[4.05 – 4.13]3.756.457.09Как видно, Gevent и Eventlet при такой нагрузке друг от друга мало чем отличаются. С натяжкой можно сказать, что gevent начинает формировать базу для превосходства над eventlet при тысячах потоков, но подобная экстраполяция будет преждевременной.

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

Гринлеты vs. Prefork

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

Prefork (concurrency=8)Gevent/Eventlet (8)Ядер использовано21Throughput (з/с)4.231.80Throughput на одно ядро2.1151.80Средняя latency (с)22.5598.68Как видно, даже на одно ядро prefork производительнее (~17%) для конкретной синтетической задачи. Latency у gevent в 4.4 раза выше (98.7 с против 22.6 с), что также ожидаемо: очередь накапливается, потому что одно ядро не справляется. Но всё-таки не ставьте крест на зелёных потоках! Они не предназначены для длительной и серьёзной нагрузки на процессор.

Зелёные потоки (gevent/eventlet)Системные процессы (prefork)ПараллелизмКооперативный (задачи сами уступают I/O)Вытесняющий (ОС переключает процессы)ПлотностьОчень высокая (тысячи зелёных потоков в одном процессе)Низкая (число процессов ограничено памятью)I/O-bound задачиОгромный выигрышПлохо (процессы дороги)CPU-bound задачиПлохо (только одно ядро)Хорошо (много ядер)time_limit / soft_time_limitНужно использовать gevent.Timeout (eventlet.Timeout)Работаютmax_tasks_per_childНет. Настраивать через supervisor/systemdРаботаетИзоляцияНет (падение одного гринлета может убить весь воркер)Падение одного процесса не влияет на остальныеMonkey patchingОбязателен (monkey.patch_all())Не нужен

Малые выводы

• Выбирайте gevent для celery в новых проектах. Eventlet официально не рекомендуется.
• Если в задаче больше 10-15% чистого CPU, стоит рассматривать prefork. Уже при 35% CPU-времени prefork ощутимо выигрывает.
• Зелёные потоки хороши для I/O-bound задач. Тысячи параллельных запросов к АПИ или БД, а потребление ресурсов на уровне одного системного процесса.
• Блокировка event loop: если гринлет забывает уступить управление (цикл без sleep или I/O или высокая ЦПУ-нагрузка), он может заблокировать весь воркер.
• Celery-time_limit иmax_tasks_per_childне работают. Штатными средствами задачу прервать не удастся. Нужно настраивать тайм-ауты внутри задачи gevent.Timeout / eventlet.Timeout.Я признаю ограничения эксперимента: заставил зеленые потоки трудиться над непривычными задачами. Поэтому постараюсь по окончании разбора Celery сделать большое сравнение пулов с реальными подключениями к БД, АПИ и какой-нибудь логикой.

Исходный код эксперимента: https://github.com/okolobackend/Celery-Architecture-and-ScalingТеги:• celery
• gevent
• eventletХабы:• Программирование
• Python