Рабочий процесс IIS (w3wp.exe) загружается до 99% ЦП при вызове службы WCF

Question

У нас есть служба .NET 3.5 WCF, размещенная на IIS 6.0, которая имеет привязку basicHttp. Это используется 2 .NET и 2 ASP приложениями. Когда запускается 4-е приложение (независимо от .NET или ASP) и пытается его использовать, w3wp.exe достигает максимума 99% и остается там через несколько секунд.

Исходя из этой статьи , мы попытались добавить следующее .NET 2.0 machine.config, но это не имеет никакого эффекта.

<processModel autoConfig="false" maxWorkerThreads="500" maxIoThreads="500" minWorkerThreads="2"/>
<httpRuntime minFreeThreads="250" minLocalRequestFreeThreads="250"/>

Есть идеи?

РЕДАКТИРОВАТЬ: Добавлена ​​информация отчета анализа сбоя:

Предупреждение 1: Следующие потоки в приложениях w3wp.exe_ v2.0 _PID_ 2856 _Date__12_08_2011__Time_12_13_39PM_ 876 _Manual Dump.dmp ожидают синхронного запроса WCF выполнить 4,35% заблокированных тем

Пожалуйста, нажмите на Actual Thread, чтобы увидеть описание потока WCF или проверьте отчет запроса WCF, чтобы узнать идентификатор потока для фактического потока WCF, для которого этот поток ожидает. Более подробную информацию об этом поведении WCF можно найти в блоге о регулировании запросов WCF и масштабируемости сервера.

Thread 16 - System ID 3920
Entry point   mscorwks!ThreadpoolMgr::intermediateThreadProc 
Create time   12/8/2011 12:10:44 PM 
Time spent in user mode   0 Days 00:00:00.031 
Time spent in kernel mode   0 Days 00:00:00.140 

This thread is waiting on a synchronous WCF request to execute

The destination WCF Thread for this ASP.NET worker thread is 14


.NET Call Stack
Function 
System.Threading.WaitHandle.WaitOneNative(Microsoft.Win32.SafeHandles.SafeWaitHandle, UInt32, Boolean, Boolean) 
System.Threading.WaitHandle.WaitOne(Int64, Boolean) 
System.Threading.WaitHandle.WaitOne(Int32, Boolean) 
System.Threading.WaitHandle.WaitOne() 
System.ServiceModel.Activation.HostedHttpRequestAsyncResult.ExecuteSynchronous(System.Web.HttpApplication, Boolean) 
System.ServiceModel.Activation.HttpModule.ProcessRequest(System.Object, System.EventArgs) 
System.Web.HttpApplication+SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() 
System.Web.HttpApplication.ExecuteStep(IExecutionStep, Boolean ByRef) 
System.Web.HttpApplication+ApplicationStepManager.ResumeSteps(System.Exception) 
System.Web.HttpApplication.System.Web.IHttpAsyncHandler.BeginProcessRequest(System.Web.HttpContext, System.AsyncCallback, System.Object) 
System.Web.HttpRuntime.ProcessRequestInternal(System.Web.HttpWorkerRequest) 
System.Web.HttpRuntime.ProcessRequestNoDemand(System.Web.HttpWorkerRequest) 
System.Web.Hosting.ISAPIRuntime.ProcessRequest(IntPtr, Int32) 

Answer 1

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

Если вы знакомы с WinDbg и уже установили и настроили его ( в противном случае потратьте немногоВремя качества с учебниками здесь ), попробуйте следующее:

.loadby sos mscorwks
.prefer_dml 1
!threads

Это покажет, сколько потоков было создано..prefer_dml 1 позволяет генерировать HTML-подобные ссылки, поэтому вы можете просто щелкнуть, чтобы запустить соответствующую команду в выходных данных.Следующий запуск:

!syncblk

, чтобы увидеть, какие потоки могут быть заблокированы.Он должен показать, какой поток выполняет блокировку.Затем запустите что-то вроде этого, чтобы получить стек для потока 32, если тот был виновником:

~32e!clrstack

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