w3wp.exe High CPU Utilization

[mcollier]

I am experiencing high CPU utilization with my ASP.NET application.
The w3wp.exe process uses 75%-80% CPU for about 10 seconds. I notice
this when the application first starts up, which I can partially
understand since ASP.NET compiles the application on the first access.
However, I also notice the high CPU usage by w3wp.exe after long
periods of inactivity. For example, if I stop using the site for 30
minutes, and then come back to the site, I see the CPU usage spike
again. As long as I continue to use the site, it is very fast.

I'm using Windows Server 2003. I have not changed any configuration
settings in ASP.NET or the .NET Framework (i.e. the machine.config
file). I have several (less than 10) assemblies in my application's
\bin directory.

I put simple log statements (to the Windows event log) in my
application's Application_Start() method. Work performed there takes
approximatley 3 seconds. So far I am unable to determine where the
remaining approximately 7 second delay comes from.

Any suggestions on places to look to determine and reduce the
application's start-up time would be greatly appreciated.


Thank You

 

[Sherif ElMetainy]

Hello

The default IIS 6 setting for an application is shutdown worker processes
after being idle for 20 minutes. So when a new request comes after 30
minutes of being idle a you said, IIS will start and initialized the worker
process again. It will JIT compile every method in your application at first
access. So you will experience a great delay on first access. You can change
this setting (and other performance settings) from IIS manager, under
Application Pools.

Best regard,
Sherif

 

[mcollier]

Why does it have to JIT it each time the process is started? I noticed
what appear to be compiled versions of the pages under the
"C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files"
directory. Wouldn't these pages be used when the worker process
restarts?

Do you know of a MSDN, or similar, site that discusses this process? I
would like to learn more about how this works.


Thanks!

 

[Alvin Bruney [ASP.NET MVP]]

one reason is that a restart may mean that files have changed. if this is
the case, then some assemblies need to be recompiled and the jit cache
should be flushed accordingly if the methods come from these dirty
assemblies

--
Regards,
Alvin Bruney
[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
available at www.lulu.com/owc
_________________________

 

[Sherif ElMetainy]

Hello

The compiled in in Temp ASP.NET files are IL dlls not native dlls they have
to be JIT compiled at runtime. The JIT compiler compiles the code to memory
and doesn't save a copy of the native code to disk. So all JIT compiler's
work is lost when the process is terminated.
The performance hit when the process is restarted is not only due to JIT. It
is also because of the process itself loading.

As I said the process restarts in your case were due to 20 minutes idle
timeout. You can simply avoid them by modifying your IIS settings. In a
production scenario, the traffic is usually higer such that the worker
process should never be idle for more than 20 minutes.

Best regards,
Sherif

 

[mcollier]

Is the default shutting down of the worker process just to conserve
system resources? The high CPU utilization from w3wp.exe likely due to
the JIT and reloading?

I'll need to find some good documentation on this process. Mainly so
that I can point my colleagues to it too.

 

[jeandemo]

Hello,
This problem showed up for me when the Symantec Mail Security for Microsoft Exchange Version 6.0.x was installed. It did not only affect this program, but is also affected ASP, Brightmail, and Microsoft Exchange directly. In fact, I became aware of the problem when Microsoft Exchange started failing intermittently. I was actually quite confused because the problems would show up in the event logs as an ASP problem, a Brightmail problem, or a Microsoft Exchange problem. I spent many a sleepless night chasing down those particular problems only to learn that Symantec Mail Security for Microsoft Exchange Version 6.0.x uses all these programs to work. That said, I have since patched the Symantec Mail Security for Microsoft Exchange Version 6.0.x to 6.5.x and it seems to have settled down completely. I hope I have been able to help. Sincerely,