Перевел прод на Python 3.14 free-threaded и через две недели откатился. Рассказываю где больно

[sainty]

Расскажу как я сходил в светлое безгильное будущее и вернулся обратно. Сервис: парсинг фидов поставщиков плюс ресайз картинок, крутился на 12 процессах через multiprocessing, жрал 9 гигов, потому что каждый процесс тащит свою копию всего на свете. Решил что пора: ставлю 3.14t (uv python install 3.14t, кстати, работает из коробки), переписываю пул процессов на ThreadPoolExecutor, общие структуры вместо Manager. На бумаге красота.

Теперь реальность.

1. Однопоток просел процентов на 8. Это известно и обещано (5-10%), но все равно неприятно.
2. Половина зависимостей без колес под cp314t. psycopg2 собирал из исходников, одна либа для exif так и не собралась, выкинул.
3. Самое смешное. Если хоть одно C-расширение не объявило поддержку free-threading, интерпретатор молча включает GIL обратно. Узнал я это через sys._is_gil_enabled() спустя ДВЕ НЕДЕЛИ. То есть я гонял free-threaded сборку с включенным гилом и радовался, что ничего не падает.
4. Выпилил виновника, гил реально выключился. И начались сегфолты раз в 4-6 часов где-то в C-кишках либы для ресайза. Под нагрузкой, естественно, в три ночи.

Откатился на 3.13 и multiprocessing, сплю спокойно. Вернусь к этой теме году в 2027. У кого-нибудь реально взлетело в проде?

[torchchan]

ворнинг при старте оно вообще-то пишет, что гил включен обратно и из-за какого модуля. stderr читать не пробовал? хах. а по делу: ставь PYTHON_GIL=0 жестко, тогда несовместимое расширение упадет прямо на импорте и ты узнаешь сразу, а не через две недели

[zfsguru]

У нас взлетело, но мы шли к этому полгода. ML-препроцессинг, чистый CPU-bound, 16 потоков. На обычном 3.13 скейлинг по потокам х1 (спасибо гилу), на 3.14t получили х9. Но: выпилили все сомнительные зависимости, numpy свежий (free-threading там нормально живет уже с 2.1), все свое нативное пересобрали и прогнали под TSan. Вот последнее прям обязательно, гонки в расширениях, которые годами молча прятались за гилом, вылезают именно так, как у тебя: сегфолт раз в несколько часов. Это не Python сломан, это твоя либа всегда была сломана, просто раньше ей не давали исполняться параллельно.

И да, для типичного веба это все пока мимо. Наш кейс узкий: числодробилка, где память общая и копировать ее в процессы дорого.

[pharside]

а почему картинки вообще на питоне ресайзите? вынесите в отдельный сервис на Go или хоть libvips дерните, и вся эта миграция не нужна

[asyncmonk]

Про subinterpreters кто-нибудь вспомнит или я один? В 3.14 же завезли concurrent.interpreters прямо в stdlib. Изоляция как у процессов, оверхед сильно меньше, гил у каждого свой. Для кейса ТС (независимые задачи, мало общего состояния) выглядит честнее, чем free-threading со всеми его сегфолтами. Сам пока гонял только на игрушечных примерах, врать не буду.

[archdev]

посчитаем. 9 гигов лишней памяти это плюс 500-700 рублей в месяц на любом vps. сколько стоили твои две недели миграции и откат, м? иногда тупое решение и есть правильное

[fandango1305]

Подтверждаю что нативные биндинги это главная боль. У нас свои на pybind11, поддержку free-threaded режима там завезли еще в 2.13, но просто перекомпилировать мало: пришлось руками расставлять локи вокруг всего, что трогает общее состояние. Зато теперь х14 на 16 ядрах и один процесс вместо зоопарка. Окупилось, но у нас это месяц работы одного человека.

[vuemaker]

не понял проблемы. возьми fastapi с асинком и не парься, зачем эти потоки вообще