Узкое место в рабочем процессе IIS 7, большое количество ожидающих запросов в пуле приложений ASP.NET 3.5 + 2.0
Я использую ASP.NET 2.0, .NET 2.0 Framework и IIS 7. Я вижу большую очередь "запросов" под опцией "рабочий процесс". Государственный зарегистрированный представляется Authenticate Request а также Execute Request Handles больше, чем что-либо.
Я исправил aspnet.config в C:\Windows\Microsoft.NET\Framework64\v2.0.50727 (32-битный путь и 64-битный путь), чтобы включить:
maxConcurrentRequestsPerCPU="50000"
maxConcurrentThreadsPerCPU="0"
requestQueueLimit="50000"
Я исправил machine.config в C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG (32-битный и 64-битный путь) для включения:
autoConfig="false"
maxIoThreads="100"
maxWorkerThreads="100"
minIoThreads="50"
minWorkerThreads="50"
minFreeThreads="176"
minLocalRequestFreeThreads="152"
Тем не менее я получаю эту проблему.
Проблема проявляется в большом количестве запросов в очереди рабочего процесса.
Количество текущих подключений к веб-сайту отображается 500, когда эта проблема возникает. Я не думаю, что видел одновременных подключений более 500 без возникновения этой проблемы.
Веб-приложение замедляется как блок запросов.
Обновление пула приложений разрешается на некоторое время (как и ожидалось), поскольку нагрузка распределяется между двумя пулами.
Рассматриваемый пул приложений FIXED REQUEST настроен на обновление 50000.
Примечание. В платформе.NET 3.5, как мне кажется, используются фреймворк 2.0 и файлы конфигурации компьютера.
Ресурсы сервера (ЦП, ОЗУ) используются не в полной мере.
3 ответа
Закончилось увеличение рабочих процессов с 1 до 2 (веб-сад). Проблема не повторялась, поскольку, хотя они и использовали сеансы, но в течение месяца не было сообщений о проблемах сеансов от конечных пользователей.
ИЗМЕНЕНО ДЛЯ ДОБАВЛЕНИЯ:
Конкретная проблема была связана с генерацией очень больших отчетов CSV, которые обрабатываются на стороне сервера рабочего процесса, а не как ошибка, просто так, как она работает. HTML-отчеты в порядке, XML-преобразование передается на стороне клиента.
Разделение рабочих процессов решало проблемы до тех пор, пока преобразование xml на стороне сервера в создание файла csv не может быть передано процессу добавления, что устранит любое влияние со стороны других пользователей. Было просто до размера файлов / количества строк, с которыми мы работали при создании отчетов CSV.
Могу ли я предложить вам взглянуть на материалы на сайте Тесс Феррандез: " Если он сломан, исправьте его, если нужно".
То, что вы хотите сделать, это захватить дамп рабочего процесса с помощью ADPlus в то время, когда вы сталкиваетесь с большим количеством запросов в очереди запросов и когда приложение начинает зависать.
Как только вы захватили этот дамп, вы хотите загрузить его в WinDBG+SOS и начать отслеживать виновника.
У Тесс есть отличная серия лабораторных работ о том, как использовать эти инструменты для достижения максимального эффекта:
Если вы можете, то вы также можете подключить к приложению профилировщик (например, PerformanceGlir от RedGate), чтобы попытаться выяснить причину.
Следуйте статье http://support.microsoft.com/kb/821268 и обновите меня, если проблема не устранена.
Вы также можете попробовать трассировку FREB в IIS 7. http://learn.iis.net/page.aspx/266/troubleshooting-failed-requests-using-tracing-in-iis-7/ устранение неисправностей-failed-requests-using-tracing-in-iis-7/