tags:

views:

54

answers:

3

Hi,

I have a website hosted under IIS 7 on Window 2008 x64. IIS is running in 64 bit mode and the site has its own Application Pool 64 bit etc. The website appears to run fine most of the time and then all of a sudden each hour it freezes the users request. They don't get a timeout message, it just hangs and appears to wait for about 2-3 minutes before returning the page.

I have monitored the Worker Process on that application pool during and see the processor is at a very steady 25%. Memory is fine and not increasing in any scary way.

I have setup Failed Request Tracing to show me every issue where a request takes more than 30 seconds and yes it records it but with no errors.

Other websites in different application pools on the same server are working fine during the outage.

Any suggestion of how I might debug this issue?

+2  A: 

Do you have IIS set to recycle worker processes on that application pool on a given schedule? You indicate you monitored it, but you didn't indicate whether or not you found it to be recycling excessively, just that the memory allocated wasn't increasing in an untoward way.

Do the IIS logs show anything unusual during the time period? Try an app like Fiddler to help debug requests to the web server.

DarkBobG
Thanks for your response. The app pool is set to recycle only if the memory exceeds 6gb and once a day in the early hours of the morning. I also have it logging it the app pool is recycled and nothing in the event log for this.We have reviewed the logs for the website requests and not strange there. Is there an IIS log i can look at?
Chris
You've probably already checked them, but you can find all the IIS related logs in: %SYSTEMROOT%\System32\LogFilesIn my case running IIS7, they appear in C:\Windows\System32\LogFiles\Have you tried stepping through the code locally during the time that the users report the behavior?Check out http://support.microsoft.com/kb/919791 as well. I know you indicated that the processor is steady at 25%, but this may help you identify which thread is running long.
DarkBobG
Thanks again. We don't use iis to log requests because they grow to large. We have tried DebugDiag but it only works for 32bit not 64. Do you know of any issues with session states being held in SQL Server, Viewstate in files or Dynamic Compression?
Chris
Ah, yes, I see that the 64bit version of DebugDiag only allows analysis, not capturing, so that doesn't help.You could install the 64bit version of the Windows Developer Debugging tools found at http://www.microsoft.com/whdc/devtools/debugging/install64bit.mspxYour last question is a bit open ended. I could write a book on the caveats of ASP.NET Session State in SQL Server, Using the Viewstate and Dynamic Compression.Nothing stands out though that points at any one of those things, though without being able to see the solution, I can't be sure.
DarkBobG
A: 

Does the Application depend on a Database that has some Job running every hour?

In case the DB is under heavy load, it would take longer for the querries to execute on your DB and therefor take longer for your web-app to process the pages.

SwissCoder
It does but we have profiled the db and not unusual going on there.
Chris
A: 

Turn out we were using a control called i-Load to resize images. It has a function to delete temp files after 3 hours. This was locking the IO and causing out entire web-app to halt. Switch it off and all work fine now. Hope this helps someone.

Chris