Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I have this web site written in c#. around 400-500 users online at any time. it was on windows 2008 32 bit machine before and never ever locked/slowed down due to increased memory consumption up until i upgraded it's server to win 2008 r2 64 bit.

Old server had only 4 gig ram and quad core cpu at 2ghz. site was working just fine. since i've upgraded the server i noticed (2 times with in 10 days) it started to eat ram. last night it went up to 4 gb ram. with ram increase response slows down quite a lot. recycling app pool doesn't help. I have to restart it's worker process to recover.

i've noticed this usually happens if there are continuous errors. as i didn't change anything in the code am i safe to assume it is not related to memory leak in the code?

did anyone came across something like that?

same thing happens if i create continuous errors with classic asp.

thanks

share|improve this question

2 Answers 2

I might have found the reason. I don't know why that didn't happen on iis7 or 6 but what happens is this.

This happens if you set iis/asp.net error pages to a dynamic page such as 500.aspx, 404.aspx and error is site wide so every request gets same error. It looks like due to session blocking iis waits previous to finish before processing dynamic error page and queues your request. as number of requests increase memory increases.

share|improve this answer

First up, as a general suggestion, unless your app definitely needs 64-bit addressing, run it in a 32-bit app pool. This naturally constrains memory use to 4GB per process.

Why might this be important? Well, because 4GB to a 64-bit application is a rounding error! If the .Net framework doesn't feel it's under memory pressure, it might not bother performing garbage collection. That's not a great answer, and I don't know why this would be the case under R2 and not R1, except for the possible memory size answer.

On Recycling: Recycling should create a new worker process on the next request, and by default gives the old one up to 90 seconds to terminate - recycling does restart the worker process (or at least, tells WAS to start a new WP next time a request arrives, and politely informs the last WP that it's being recycled). Unless Overlapping Recycling is disabled, you should see a new w3wp with a new PID as soon as the next request for that site is received.

If you're still seeing the leak in a 32-bit app pool, you'll need to troubleshoot it as a memory leak - consider taking a memory dump of the process when it's in the high memory state, and then look at debugging it with sos.dll or psscor2.dll to find the primary consumer of the memory.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.