Масштабирование многопроцессорной очереди Python для большого числа рабочих

Question

У меня есть приложение python (2.6.5 64-bit, Windows 2008 Server R2), которое запускает рабочие процессы. Родительский процесс помещает задания в очередь заданий, из которой их получают работники. Точно так же у него есть очередь результатов. Каждый работник выполняет свою работу, запрашивая сервер. Использование ЦП работниками низкое.

Когда число рабочих растет, загрузка ЦП на серверах фактически сокращается. Сами серверы не являются узким местом, так как я могу загружать их дальше из других приложений.

Кто-нибудь еще видел подобное поведение? Существует ли проблема с многопроцессорными очередями python, когда большое количество процессов читает или записывает в одни и те же очереди?

Answer 1

Две разные идеи для ограничения производительности:

1. Узким местом являются рабочие, сражающиеся друг с другом и родителем за доступ к очереди заданий.
2. Узким местом являются ограничения скорости соединения(защита от смещения потока) на серверах.

Сбор дополнительной информации:

1. Профилирование объема выполненных работ: задач, выполняемых в секунду, используйте это в качестве основной производительностиметрика.
2. Используйте захват пакетов для просмотра сетевой активности на предмет задержек на уровне сети.
3. Пусть ваши работники задокументируют, как долго они ожидают доступа к очереди заданий.

Возможные улучшения:

1. Пусть ваши работники используют постоянные соединения, если они доступны / применимы (например, HTTP).
2. Разделите задачи на несколько очередей заданий, подаваемых в пулы работников.

Answer 2

Создание новой команды - очень дорогая операция.

Один из самых простых способов управления множеством сетевых подключений paralell - это использование потоков без стеков с поддержкой асинхронных сокетов.У Python была отличная поддержка и куча библиотек для этого.

Мой любимый - gevent , в котором есть замечательная и полностью прозрачная утилита исправления обезьян.

Answer 3

Не совсем уверен, что происходит, если вы не предоставите все детали.

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