I am having a problem with High CPU happening on my my website in IIS8. This happens randomly and not very often but it does happen especially when the load is heavy on the site. The only way to stop it is to End Task on the w3wp.exe process and it’s fine.
I tried to to do a debug diagnosis below but I cant seem to figure out what exactly it means or how to read it since it doesnt provider much info. Is there something else I should do to verify what the actually problem area is?
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 detailsThread 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
Answer
Obviously you make too much garbage, so the GC takes too much time to collect it. Happens when you have bad programming.
So, grab a memory profiler and analyze where the garbage comes from. Then fix the crapping code.
Attribution
Source : Link , Question Author : exposure , Answer Author : TomTom
