Высокая загрузка ЦП вызвана сборкой мусора в 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
задан 26 April 2016 в 04:54
1 ответ

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

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

1
ответ дан 5 December 2019 в 19:48

Теги

Похожие вопросы