Dated: September 20, 2004
On September 16th, some customers complained of getting intermittent Outofstorage and ASP related issues on their sites on Win5. We had determined the problem was due to excessive memory usage caused by a website that was filling up the ram very quickly at peak times. We started doing proactive IIS recycles to ensure that RAM usage stays within permissible levels (preventing further issues) till we tracked down the website.
I'd just like to confirm that we traced the website after 4 days (or 96 hours) of continuous monitoring and troubleshooting. The website (which we have disabled) was eating upto 1GB of RAM, and very quickly. What made it difficult to track was there were only specific scripts on this website causing the issue and it didn't initially figure as a suspect.
I'd just like to say that its important for customers to understand and determine the impact of their scripts before running them on our servers. Our servers are not test servers, they are production servers serving businesses and electronic commerce and a bad script can cause problems. Tracking down such sites is a very time-consuming process (we wasted 96 hours of valuable administrative time). Its of utmost importance that customers close their db connections properly and that if they are dealing with large data or processing complex queries, they stress test them locally
On September 16th, some customers complained of getting intermittent Outofstorage and ASP related issues on their sites on Win5. We had determined the problem was due to excessive memory usage caused by a website that was filling up the ram very quickly at peak times. We started doing proactive IIS recycles to ensure that RAM usage stays within permissible levels (preventing further issues) till we tracked down the website.
I'd just like to confirm that we traced the website after 4 days (or 96 hours) of continuous monitoring and troubleshooting. The website (which we have disabled) was eating upto 1GB of RAM, and very quickly. What made it difficult to track was there were only specific scripts on this website causing the issue and it didn't initially figure as a suspect.
I'd just like to say that its important for customers to understand and determine the impact of their scripts before running them on our servers. Our servers are not test servers, they are production servers serving businesses and electronic commerce and a bad script can cause problems. Tracking down such sites is a very time-consuming process (we wasted 96 hours of valuable administrative time). Its of utmost importance that customers close their db connections properly and that if they are dealing with large data or processing complex queries, they stress test them locally