Windows распределяет потоки Python по ядрам?

Question

[GreenX5]

Как известно, Python базово однопоточный, GIL виноват и т.д.
Поднимаем вебсервер на Python, под каждый запрос посетителя создаем отдельный thread чтобы быстро освобождать вход, нагрузка растет, threads одновременно уже сотни, вопрос - начнет винда распределять их по ядрам, или только самому ручками стряпать распределитель?
Собственно вопрос из целесообразности многоядерного сервера без ворот типа nginx.

Answer 1

[Сергей Горностаев]

Начнёт, но работать в один момент времени будет только одно ядро. Утилизация процессоров в Python решается запуском отдельного процесса на каждое ядро, а внутри процесса лучше использовать асинхронность, а не многопоточность.

Comments

[GreenX5]

Сергей, спасибо! Верный в таком случае выбор железа под async - максимально быстрые ядра, а много их не нужно?

[Сергей Горностаев]

GreenX5, это зависит от решаемой задачи, не всё можно асинхронить. Да и сервер ведь не один только скрипт обслуживает.

[GreenX5]

Спасибо. Ваш ответ породил новые вопросы для решения задачи, но их наверное уместно задать отдельными вопросами )

[Сергей Горностаев]

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

[Vindicar]

SKEPTIC, Я не думаю, что питон предоставляет такое апи - оно очень зависит от ОС. Но если прямо позарез нужно, можно попробовать дёрнуть из питона WinAPI, а именно SetProcessAffinityMask(). Достучаться до WinAPI вполне реально.

Answer 2

[Армянское Радио]

Запуск тредов в количестве, которое превышает количество ядер - это путь к драматическому росту latency и падению скорости.

Что в Windows (IO Completion Ports), что в Linux (epoll), все самые свежие механизмы обслуживания массовых TCP подключений запускают ровно столько тредов, сколько есть ядер, и спулят между ними события из сокетов. Именно поэтому перед разного рода скриптульками на Питоне ставят Большого Железного Феликса (nginx), который будет оптимально запихивать IO в нужные задачи.

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