IIS 5 & IIS 6
Determine Applications Causing Recycles
Last post Mar 08, 2008 11:57 PM by steve schofield
Mar 04, 2008 11:26 AM|crisco96|LINK
We have multiple applications (10-20) inside an application pool, and not all of them are directly controlled by us. The problem is every once and a while the application pool will start recycling a lot and we have no easy way to tell which application(s)
is causing it. Ideally I was wondering if there's anything that displays a sort of dashboard that will show the amount of memory each application in the pool is using (so we can figure out which ones are the hogs), or if there's some way in code (either .Net
or classic asp) to get the amount of memory that's being used by the current application.
I've looked into DebugDiag but this doesn't seem to give me the amount of memory a particular application is using.
Mar 04, 2008 10:44 PM|qbernard|LINK
You would need to isolate each app to its own app pool then monitor the app pools.
Mar 06, 2008 10:09 AM|Number09|LINK
Ouch! I hope not, I've just posted about a similar issue (Mods if you want to merge: http://forums.iis.net/t/1148288.aspx) but with a fair few more web apps, it would be unfeasible to isolate them all.
If such an application doesn't exist then this is quite a gap in the market, I should learn to code ;)
Mar 06, 2008 11:23 AM|Number09|LINK
I've implemented the changes described here:
Its writing lots more information to the Event Log, hopefully this will provide helpful
Mar 07, 2008 11:29 AM|crisco96|LINK
The server admin will not split all apps into their own pools. In addition doing so may not find the culprit because the recycles may be caused by a combination of apps.
Mar 08, 2008 09:31 PM|qbernard|LINK
Well, this is the normal practice. without isolating the app - how would you narrow down? of coz you can try debugdiag and wait for it to crash and dump the log yet there will be many details inside as may apps sharing the same worker process. And isolating
out would let you identify lot quicker on which worker process crash, etc.
Regarding - caused by a combination of apps - logic part yes, but physically - only one thread or one particular query or request or logic or component or coding that causing exception etc. so it is still 1 ? say for example long sql query... all threads
got hold up by one when it is still waiting for sql to response, etc.
Hence, isolating not only allow you to narrow down the scope, it also allow you to isolate legacy app, 3rd party etc to be part of your app solution but not sitting together with the rest in other app pool, this gives you better control, robustness, etc
advantage over putting everything in to one app pool.
anyway, if you can debug it with all apps sharing a single app pool, so be it. find the error and fix it.
Mar 08, 2008 11:57 PM|steve schofield|LINK
If people are uploading files at will, including new web.config's, files '/bin', this would cause a recycle. I would do a search for new files including DLL, files in App_Code (assuming this is asp.net) and web.config files. This might help determine or
at least narrow down the culprit.
Windows Server MVP - IIS
Log archival solution
Install, Configure, Forget