How can i diagnose IIS pushing the CPU to 100% usage?

Question

I have a web server with more than a few ASP.NET sites running on it. Every so often, i notice that IIS is pushing the server's CPU to 100%. The sites share application pools, per .NET version they are running.

What i'm looking for is a way to be able to pinpoint which site it is that is doing this, using some tool. If that tool happened to get down into the code to show it, that would also be nice. If not, i'm happy just knowing which site is causing the issue.

I've already tried using ANTS. However, with ANTS you need to know which site it is, and then have it running and waiting on said CPU-crashing web app. Not perfectly ideal.

Any experience/ideas?

Answer 1

Use task manager to get the PID of the process that is taking all of the CPU, then use the answers to this question to match the PID to the web site.

Answer 2

Check the IIS Debug Diagnostics tool http://support.microsoft.com/kb/919790,

another approach, break each site into different app pools and then watch the app pools in Task Manager to see the memory usage.

Answer 3

In addition to David's (correct) answer, once you've identified the WS in question, VS2010 with team tools has some fantastic performance analysis stuff under the "Analyze" menu. With the tools in there, you should be able to narrow your problems down to specific lines of code in no time.

It's stupidly simple to use the Performance Analysis Wizard - just point it at the project in question, let it launch, run through various actions on the site and it will give you every metric you need to find your problem (it even puts flame icons next to the CPU-intensive code in the editor)

Answer 4

Low-tech answer:
+ Use the Task Manager to identify the loaded worker process.
+ Use c:\windows\system32\issapp.vbs to identify the app pool name of the loaded process (alternatively, DebugDiag does the same thing more easily, if you're familiar with that tool. There's a column header for App Pool name on the Process Tab.)
+ Create new app pools and split your apps between them until you can isolate the app causing the problem into an app pool all by itself.

More technical answer:
+ Use the Task Manager to identify the loaded worker process. Hang dump that worker process using DebugDiag or ADPlus -hang -p (a part of Debugging Tools for Windows, both free downloads from Microsoft)
+ DebugDiag can pre-analyze the hang dump for you, and may just give you all the clues you need. That's a medium tech solution that often works. You'll want to look at the process tab and right click on the offending process. Choose "Full Usermode Dump" or something like that. Find the created dump file at c:\Program Files\DebugDiag\Logs\Misc*.dmp and double-click it to see the pre-analysis.
+ If DebugDiag doesn't give you enough clues, then WinDBG can certainly tell you what you need to know, though it's an arcane and difficult tool to even begin with, much less master. (It's also a whole lot of fun. I highly recommend it if you're an admin and frequently asked such questions. )