Website slowdown

Question

I have a website that randomly grinds to a halt. At first I thought this was due to the number of users in the system and database connections being left open but when it occurred today I ignored the database server and simply stopped IIS, killed the w3wp.exe processes (There were a number of them), started IIS and everything was back to normal.

There were/are around 17 w3wp.exe processes all using between 200,000K and 400,000K which seems like a lot to me. But the web server wasn't running out of memory, we have 24 gig of which 7 was being used. The CPU also appeared fine.

At the moment the system isn't under load and the w3wp.exe processes are hitting around 150,000K to 200,000K.

Any ideas as to what the problem could be?

score 0 · Answer 1 · answered Dec 17 '10 at 18:51

0

Check the Pool Nonpaged Bytes counter the next time the problem occurs. The limit on a W2K3 server with a default boot.ini file is 256MB. If the Pool Nonpaged Bytes is approaching that amount it will cause problems with IIS.

answered Dec 17 '10 at 18:51

joeqwerty

109,901
6
81
172

It's a windows 2008 64 bit server if that makes a difference. Is there a way to up that limit? – Jack Mills Dec 17 '10 at 18:57
Well, that probably changes things then. For IIS on W2K8 x64 I have no idea. Sorry. – joeqwerty Dec 17 '10 at 20:54

score 0 · Answer 2 · answered May 10 '11 at 05:37

Community Poke!

You've said it's "one website" but you have 17 W3WPs?

Traditionally/typically/customarily/conventionally/by default, worker processes are configured for one WP per app pool. You can turn it up to eleven (to an arbitrary number, actually), but it's of limited use as a single WP for the average app usually performs better than tons of them.

So, if it's configured > 1, why?

Are the other W3WPs for the same site? App? App Pool?

Diagnosis

If all W3WPs stop serving content at the same time, that's an Interesting Problem. Use ProcDump or Task Manager to create a dump of the W3WPs that are problematic.

Once you've got the dump, proceed to Recovery, and when everything's running fine later, you can take the memory dump files produced earlier and either use DebugDiag or feed it into WinDBG (or read a WinDBG tutorial online, or find someone that can do this), and look at what the threads are all waiting on. That'll typically tell you where the problem seems to be, and that'll define a troubleshooting path.

Recovery

Try recycling individual W3WPs next time. If they're being recalcitrant, you can r-click and End Process in Task Manager, and the next request should start a replacement. (Doing this more than 5x in 5 minutes will cause the App Pool to Stop, so avoid mass killoffs, and use the UI to recycle them).

Website slowdown

2 Answers2