У меня проблема с высокой загрузкой процессора на моем веб-сайте в IIS8. Это происходит случайно и не очень часто, но случается, особенно когда на сайте большая нагрузка. Единственный способ остановить это - завершить задачу в процессе w3wp.exe, и все в порядке.
Я попытался выполнить диагностику отладки, приведенную ниже, но, похоже, не могу понять, что именно это означает или как ее читать, поскольку он не предоставляет много информации. Что еще мне нужно сделать, чтобы проверить, в чем на самом деле проблема?
In w3wp.exe__example.com__PID__4944__Date__04_25_2016__Time_10_28_23AM__521__PERFTRIGGER_RULE1.dmp GC is running in this process. The Thread that triggered the GC is 338
When a GC is running the .NET objects are not in a valid state and the reported analysis may be inaccurate. Also, the thread that triggered the Garbage collection may or may not be a problematic thread. Too many garbage collections in a process are bad for the performance of the application. Too many GC's in a process may indicate a memory pressure or symptoms of fragmenation. Review the blog ASP.NET Case Study: High CPU in GC - Large objects and high allocation rates for more details
Тема 338
Entry point 0x00000000
Create time 4/25/2016 10:26:26 AM
Time spent in user mode 0 Days 00:00:02.750
Time spent in kernel mode 0 Days 00:00:00.00
This thread is incomplete and also has/have an invalid Thread Environment Block pointer. As a result, the information reported is most likely inaccurate.
.NET Call Stack
Function
System.Web.Hosting.UnsafeIISMethods.MgdIndicateCompletion(IntPtr, System.Web.RequestNotificationStatus ByRef)
Full Call Stack
Function Source
ntdll!NtWaitForSingleObject+c
KERNELBASE!WaitForSingleObjectEx+99
clr!CLREventWaitHelper2+31
clr!CLREventWaitHelper+2a
clr!CLREventBase::WaitEx+152
clr!SVR::gc_heap::wait_for_gc_done+66
clr!SVR::GCHeap::GarbageCollectGeneration+1c2
clr!SVR::gc_heap::try_allocate_more_space+149
clr!SVR::gc_heap::allocate_more_space+35
clr!SVR::GCHeap::Alloc+8f
clr!Alloc+54
clr!AllocateObject+94
clr!JIT_New+6b
System_Core_ni+1e7a90
System_Core_ni+1e7a61
System_Core_ni+1db6ad
System_Core_ni+1eb05a
System_Core_ni+1e808b
System_Core_ni+1ec3b0
System_Core_ni+1eb20e
System_Core_ni+1db6ad
System_Core_ni+1eb05a
System_Core_ni+1e808b
System_Core_ni+1ec3b0
System_Core_ni+1eb20e
System_Core_ni+1db6ad
System_Core_ni+1eb05a
0x203fec01
0x2272d822
System_Web_ni+1dead7
System_Web_ni+80a2df
System_Web_ni+809f42
System_Web_ni+809eee
System_Web_ni+8095ad
0x229a7c6c
0x229a7948
0x1aebccaf
0x229a0c2e
0x229a0a9a
0x2298d7a3
0x229a0131
0x229a0afb
0x229a18f8
0x229a219e
0x2298d7ab
0x22988cb9
0x22982eb4
0x2298222c
0x22981fce
0x22981d69
0x22981e50
0x22981e50
0x22981e50
0x22981c25
0x227caa8e
0x227cab65
System_Web_ni+b40d76
System_Web_ni+1e2e15
Очевидно, что вы делаете слишком много мусора, поэтому ГХ занимает слишком много времени, чтобы собрать его. Случается, когда вы плохо программируете.
Итак, возьмите профилировщик памяти и проанализируйте, откуда взялся мусор. Затем исправьте код крэппинга.