Windows, несколько процессов и несколько потоков

Question

Мы должны сделать нашу систему очень масштабируемой и она была разработана для платформы Windows с использованием VC++. Скажем сначала, мы хотели бы обрабатывать 100 запросов (из msmq) одновременно. Какой был бы лучший подход? Один процесс с 100 потоками или 2 процессами с 50-50 потоками? Какая прибыль зависит от памяти процесса в случае второго подхода. в Windows первое процессорное время выделяется для процесса, а затем разделяется между потоками для этого процесса, или ОС подсчитывает количество потоков для каждого процесса и выделяет ЦП на основе потоков, а не процессов. Мы заметили, что в первом случае загрузка процессора составляет 15-25%, и мы хотим потреблять больше CPU. Помните, что мы хотели бы получить оптимальную производительность, таким образом, 100 запросов, например, являются примерами. Мы также заметили, что если мы увеличим количество потоков процесса выше 120, производительность ухудшится из-за переключений контекста.

Еще один пункт; наш продукт уже поддерживает кластеризацию, но мы хотим использовать больше процессора на одном узле.

Любые предложения будут высоко оценены.

Answer 1

Стандартный подход к окнам - несколько потоков. Не говоря, что это всегда ваше лучшее решение, но есть цена, которую нужно заплатить за каждую нить или процесс, а в окнах процесс дороже. Что касается планировщика, я не уверен, но вы можете установить приоритет процесса и потоков. Реальная польза для потоков - это их общее адресное пространство и возможность общения без IPC, однако синхронизация должна быть тщательно поддержана.

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

только мои +0,02

Answer 2

Вы косяк процесса больше запросов, чем вы ядра процессора. «Быстрые» масштабируемые решения включают в себя создание пулов потоков, где количество активных (не заблокированных в IO) потоков - количество ядер ЦП. Таким образом, создание 100 потоков, потому что вы хотите обслуживать 100 мсqq запросов, не является хорошим дизайном.

В Windows есть механизм объединения потоков, который называется IO Completion Ports.

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

«Ядро» идея ввода-вывода ввода-вывода заключается в том, что его очередь режима ядра - вы можете вручную отправлять события в очередь или получать асинхронные завершения ввода-вывода, отправленные в нее автоматически, связывая файл (файл, сокет, обрабатывает порт.

С другой стороны, механизм ввода-вывода IO автоматически деактивирует события на потоках ожидающих работников, но он НЕ отменяет задания, если обнаруживает, что текущие «активные» потоки в пуле потоков> = количество ядер ЦП.

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

Если ваши службы разработаны на языке C++, вы можете обнаружить, что сериализованный доступ к куче большой минус производительности - хотя Windows версии 6.1, похоже, реализовала низкую кучу соперников, поэтому это может быть меньше проблемы.

Подводя итог - теоретически ваш самый большой прирост производительности будет за счет разработки пулов потоков, управляемых одним процессом. Но вы сильно зависите от библиотек, которые используете, чтобы не сериализовать доступ к критическим ресурсам, что может быстро избавить вас от всех теоретических показателей производительности. Если у вас есть код библиотеки, сериализующий вашу службу с хорошим потоком (как в случае создания объекта C++ & уничтожение происходит из-за конфликта кучи), тогда вам нужно изменить использование библиотеки/переключателя на низкоконфликтную версию библиотеки или просто масштабировать до нескольких процессов.

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