IIS - w3wp.exe CPU Utilization

Asked By ao

20-Aug-07 07:47 AM

I've browsed the newsgroup for an answer, however, most posts stated
to post the results of the DebugDaig.

I have an issue with w3wp.exe utilizing up to 99% of the CPU.  I have
isolated the actual application pool and have ran the diagnostic
tool.  The report was VERY large, so I just posted the top 5 threads
by CPU time below.

Can someone please help me determine what the problem can be and
provide insight on how I can fix it?

Thanks!!!

Below is the report:

Type of Analysis Performed   Hang Analysis
Machine Name   SV1680
Operating System   Windows Server 2003 Service Pack 2
Number Of Processors   2
Process ID   16800
Process Image   c:\WINDOWS\system32\inetsrv\w3wp.exe
System Up-Time   4 day(s) 12:43:01
Process Up-Time   01:41:38



Top 5 Threads by CPU time
Note - Times include both user mode and kernel mode for each thread
Thread ID: 39     Total CPU Time: 00:03:51.296     Entry Point for
Thread: mscorwks!Thread::intermediateThreadProc
Thread ID: 40     Total CPU Time: 00:02:53.671     Entry Point for
Thread: mscorwks!Thread::intermediateThreadProc
Thread ID: 23     Total CPU Time: 00:02:47.936     Entry Point for
Thread: mscorwks!SVR::gc_heap::gc_thread_stub
Thread ID: 24     Total CPU Time: 00:02:25.156     Entry Point for
Thread: mscorwks!SVR::gc_heap::gc_thread_stub
Thread ID: 21     Total CPU Time: 00:00:14.718     Entry Point for
Thread: mscorwks!ThreadpoolMgr::intermediateThreadProc


Thread 39 - System ID 17484
Entry point   mscorwks!Thread::intermediateThreadProc
Create time   8/19/2007 9:09:18 PM
Time spent in user mode   0 Days 00:02:35.187
Time spent in kernel mode   0 Days 00:01:16.109




Function   Source
ntdll!KiFastSystemCallRet
ntdll!NtWaitForSingleObject+c
kernel32!WaitForSingleObjectEx+ac
mscorwks!PEImage::LoadImage+199
mscorwks!CLREvent::WaitEx+117
mscorwks!CLREvent::Wait+17
mscorwks!SVR::gc_heap::wait_for_gc_done+99
mscorwks!SVR::gc_heap::try_allocate_more_space+17
mscorwks!SVR::gc_heap::allocate_more_space+2f
mscorwks!SVR::gc_heap::allocate_large_object+86
mscorwks!SVR::GCHeap::Alloc+bc
mscorwks!Alloc+60
mscorwks!SlowAllocateString+29
mscorwks!FramedAllocateString+a0
mscorlib_ni+29c01f
System_Web_ni+223a84
System_Web_ni+223ad0
System_Web_ni+23386f
System_Web_ni+234a1b
System_Web_ni+234967
System_Web_ni+234887
System_Web_ni+d27d4
System_Web_ni+a15b5
System_Web_ni+b32e0
System_Web_ni+a0225
System_Web_ni+a550b
mscorlib_ni+299bb8




Back to Top


Thread 40 - System ID 18372
Entry point   mscorwks!Thread::intermediateThreadProc
Create time   8/19/2007 9:45:55 PM
Time spent in user mode   0 Days 00:01:44.578
Time spent in kernel mode   0 Days 00:01:09.093




Function   Source
ntdll!KiFastSystemCallRet
ntdll!NtWaitForSingleObject+c
kernel32!WaitForSingleObjectEx+ac
mscorwks!PEImage::LoadImage+199
mscorwks!CLREvent::WaitEx+117
mscorwks!CLREvent::Wait+17
mscorwks!SVR::gc_heap::wait_for_gc_done+99
mscorwks!SVR::GCHeap::GarbageCollectGeneration+267
mscorwks!SVR::gc_heap::try_allocate_more_space+1c0
mscorwks!SVR::gc_heap::allocate_more_space+2f
mscorwks!SVR::gc_heap::allocate_large_object+86
mscorwks!SVR::GCHeap::Alloc+bc
mscorwks!Alloc+60
mscorwks!SlowAllocateString+29
mscorwks!FramedAllocateString+a0
mscorlib_ni+29c01f
Microsoft_VisualBasic_ni+5e49b
System_Web_ni+223a84
System_Web_ni+223ad0
System_Web_ni+23386f
System_Web_ni+234a1b
System_Web_ni+234967
System_Web_ni+234887
System_Web_ni+d27d4
System_Web_ni+a15b5
System_Web_ni+b32e0
System_Web_ni+a0225
System_Web_ni+a550b
mscorlib_ni+299bb8


Thread 23 - System ID 11568
Entry point   mscorwks!SVR::gc_heap::gc_thread_stub
Create time   8/19/2007 8:10:40 PM
Time spent in user mode   0 Days 00:02:05.796
Time spent in kernel mode   0 Days 00:00:42.140




Function   Source
ntdll!KiFastSystemCallRet
ntdll!NtProtectVirtualMemory+c
kernel32!VirtualProtectEx+20
kernel32!VirtualProtect+18
mscorwks!EEVirtualProtect+84
mscorwks!CExecutionEngine::ClrVirtualProtect+15
mscorwks!ClrVirtualProtect+1b
mscorwks!CpuStoreBufferControl::FlushStoreBuffers+2a
mscorwks!Thread::SysSuspendForGC+14f
mscorwks!SVR::GCHeap::SuspendEE+16c
mscorwks!SVR::gc_heap::gc_thread_function+3b
mscorwks!SVR::gc_heap::gc_thread_stub+9b
kernel32!BaseThreadStart+34




Back to Top


Thread 24 - System ID 16748
Entry point   mscorwks!SVR::gc_heap::gc_thread_stub
Create time   8/19/2007 8:10:40 PM
Time spent in user mode   0 Days 00:02:12.250
Time spent in kernel mode   0 Days 00:00:12.906




Function   Source
ntdll!KiFastSystemCallRet
ntdll!NtWaitForSingleObject+c
kernel32!WaitForSingleObjectEx+ac
mscorwks!PEImage::LoadImage+199
mscorwks!CLREvent::WaitEx+117
mscorwks!CLREvent::Wait+17
mscorwks!SVR::gc_heap::gc_thread_function+58
mscorwks!SVR::gc_heap::gc_thread_stub+9b
kernel32!BaseThreadStart+34

Thread 21 - System ID 15288
Entry point   mscorwks!ThreadpoolMgr::intermediateThreadProc
Create time   8/19/2007 8:10:40 PM
Time spent in user mode   0 Days 00:00:12.234
Time spent in kernel mode   0 Days 00:00:02.484




Function   Source
ntdll!KiFastSystemCallRet
ntdll!NtWaitForSingleObject+c
kernel32!WaitForSingleObjectEx+ac
mscorwks!PEImage::LoadImage+199
mscorwks!CLREvent::WaitEx+117
mscorwks!CLREvent::Wait+17
mscorwks!ThreadpoolMgr::SafeWait+73
mscorwks!ThreadpoolMgr::WorkerThreadStart+f5
mscorwks!ThreadpoolMgr::intermediateThreadProc+49
kernel32!BaseThreadStart+34

Other info:
COM+ STA ThreadPool Report
Max STA Threads     50
Min STA Threads     4
Current STA Threads     4
g_activitiesPerThread     1
EmulateMTSBehavior     False
STA Threads In-Call     0  (none)




Note: There was an error collecting details for the COM+ STA
Threadpool threads. The internal COM+ data structures may have been
corrupted.


Well-Known COM STA Threads Report
STA Name    Thread ID    Thread Status    Call Status

Main STA    15 Idle    (N/A)



HTTP report
IIS ATQ worker thread count   5 Thread(s)
Available ATQ worker thread count   5 Thread(s)
Active client connections   31 client connection(s)

20-Aug-07 08:15 AM

Can you manage to see which ASPX was running during the High Peak?

This can be 'seen' more or less, in the W3SVC Log files and iisstate also
should report which page was running.

20-Aug-07 08:27 AM

Looks like you are running a .Net Application which is leaking memory
-- I mean, waiting for Garbage Collection to free up resources instead
of managing memory better. When the GC happens, the w3wp.exe CPU goes
to 100% and no managed code executes. The GC is the price you pay for
writing managed code.

You probably want to start by analyzing what managed/native objects
you are leaking (i.e. not disposing quickly enough) to avoid the GC.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

20-Aug-07 08:41 AM

Yes, it is a .NET application and I have figured out which one it is.
I isolated it into it's own application pool.

After posting my original post, I found the site that has the IISState
and will be installing that.  I am hoping to isolate this down to the
exact page that is causing the problem.

I will post the results of IISState later today.

Thank you VERY much for not only your response, but also how fast you
all responded!!!