![w3wp.exe 中的垃圾收集导致 CPU 过高](https://linux22.com/image/681579/w3wp.exe%20%E4%B8%AD%E7%9A%84%E5%9E%83%E5%9C%BE%E6%94%B6%E9%9B%86%E5%AF%BC%E8%87%B4%20CPU%20%E8%BF%87%E9%AB%98%20.png)
我在 IIS8 中遇到了网站 CPU 过高的问题。这种情况随机发生,并不常见,但确实会发生,尤其是在网站负载过重时。阻止它的唯一方法是结束 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
答案1
显然你制造了太多垃圾,所以 GC 需要花费太多时间来收集它们。当你的编程很糟糕时就会发生这种情况。
因此,请获取内存分析器并分析垃圾来自何处。然后修复垃圾代码。