#asp.net #multithreading #cpu-usage #w3wp.exe #system-idle-process
#asp.net #многопоточность #загрузка процессора #w3wp.exe #system-idle-process
Вопрос:
У меня есть многопоточное веб-приложение с примерно 1000 ~ 2000 потоками в производственной среде.
Я ожидаю, что загрузка процессора будет, w3wp.exe но System Idle Process потребляет процессор. Почему?
Комментарии:
1. Редко бывает веская причина для наличия 1000 потоков.
2. Что, предположительно , должны делать потоки?
3. Они подключаются к внешним ресурсам и передают данные в
shared buffer, затем другой поток удаляет данные и использует их. Есть вероятность, что загрузка процессора связана с управлением памятью с помощью CLR, поскольку у меня былаLOHпроблема, и теперь я используюbuffer manager. После пика потоков возникла проблема с процессором.
Ответ №1:
Процесс ожидания на самом деле не является реальным процессом, он не «съедает» ваше процессорное время. % cpu, который вы видите рядом с ним, на самом деле является неиспользуемым% cpu (более или менее).
Причина низкой производительности вашего приложения, скорее всего, связана с вашими 2000 потоками. Windows (или вообще любая операционная система) никогда не предназначалась для одновременного запуска такого количества потоков. Вы тратите большую часть времени на простое переключение контекста между ними, каждый из которых получает пару миллисекунд времени обработки каждые ~ 30 секунд (15 мс * 2000 = 30 сек !!!!).
Переосмыслите свое приложение.
Комментарии:
1. Хороший момент о накладных расходах на переключение контекста. (Я знаю, что это другой случай, но из любопытства: разве мэйнфреймы или суперкомпьютеры не были бы рассчитаны на запуск тысяч потоков? Время настенных часов обычно не является ограничением, поэтому может быть меньше переключений контекста в единицу времени …)
2. Наоборот, они вообще не использовали бы потоки. Если бы я спроектировал мэйнфрейм, который принимал тысячи заданий, я бы выполнял их одно за другим в том порядке, в котором они были мне предоставлены (FIFO). Это обеспечило бы минимальное количество потраченного впустую процессорного времени. Эти приложения написаны для обработки БОЛЬШОГО количества данных, они не будут привязаны к вводу-выводу.
3. Имейте в виду, что, если не учитывать проблемы, связанные с вводом-выводом, многопоточность предназначена для людей, чтобы создать у них впечатление о скорости. На самом деле вы теряете скорость, принудительно переключая контекст, просто кажется , что это быстрее, потому что это началось раньше.
4. Вы действительно совершенно правы; глупый я, вообще забывающий о последовательной обработке.
Ответ №2:
процесс ожидания просто задерживает время обработки до тех пор, пока это не понадобится программе, на самом деле он вообще не потребляет никаких циклов. вы можете рассматривать время простоя системы как «доступный процессор»
Комментарии:
1. Под
Task Managerон показывает загрузку процессора на 50-70%,System Idle Processгдеw2wpиспользуется только 2-5%
Ответ №3:
System Idle Process это не реальный процесс, он представляет неиспользованное процессорное время.
Это означает, что ваше приложение не использует процессор полностью — возможно, оно ограничено памятью или процессором; возможно, потоки ожидают друг друга или внешних ресурсов? Накладные расходы на переключение контекста также могут быть причиной — если у вас нет 2000 ядер, потоки не фактически выполняются одновременно, но назначенные планировщиком задач временные интервалы, это также занимает некоторое время.
Ответ №4:
Вы не предоставили много подробностей, поэтому на данный момент я могу только строить догадки. Я бы сказал, что, вероятно, большинство этих потоков ничего не делают. Те, которые что-то делают, вероятно, связаны с вводом-выводом, что означает, что они тратят большую часть времени на ожидание ответа внешнего ресурса.
Теперь давайте поговорим о «1000 ~ 2000 потоках». Существует очень мало случаев (возможно, ни одного), когда наличие такого количества потоков является хорошей идеей. Я думаю, что ваша текущая проблема является прекрасным примером того, почему. Большинство этих потоков (по-видимому, в любом случае) ничего не делают, кроме пустой траты ресурсов. Если вы хотите обрабатывать несколько задач параллельно, особенно если они связаны с вводом-выводом, то лучше воспользоваться объединенными ресурсами, такими как ThreadPool или с помощью библиотеки параллельных задач.
Комментарии:
1. На самом деле это потоки из ASP.NET пул потоков. Каждые два потока (пара потоков) отвечают за выполнение запроса. Я планировал использовать, но изменил дизайн на выделенные потоки для запросов. Помогает ли мне переход на
HttpAsyncHandlerи уменьшение количества потоков?2. @Xaqron: Возможно. Не могли бы вы попробовать с другим количеством потоков (10,50,100,200,300, …, 3000) и измерить, есть ли существенная разница в производительности?