Высокая загрузка ЦП, вызванная сборкой мусора в w3wp.exe

У меня проблема с высокой загрузкой процессора на моем веб-сайте в 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 

1 ответ

Очевидно, вы делаете слишком много мусора, поэтому сборщик мусора занимает слишком много времени. Бывает, когда у тебя плохое программирование.

Итак, возьмите профилировщик памяти и проанализируйте, откуда берется мусор. Затем исправьте код взлома.

Другие вопросы по тегам