Please note: In an effort to better serve you, we are in the process of restructuring DevCenter. In the process, we have moved many items that you may be used to finding in DevCenter over to the Main Site. If you are having trouble locating something, please try looking at the following places:
What is considered high memory?This is going to be dependent on volume and activity of specific applications, but in general, high memory is when see that your Aspnet_wp.exe process (Internet Information Services (IIS) 5.0) or W3wp process (IIS 6.0) memory is consistently increasing and is not returning to a comfortable level. In very general terms, a comfortable level would be under 600 MB in the default 2 GB user memory address space. Once the memory level is higher than that, we are performing less than we should be, and this may affect other applications running on the system. The key here is to understand that some applications require more memory than others, and if you are exceeding these limits, you may want to add more memory or add another server to your Web farm (or consider a Web farm). Also, profiling is recommended in these cases, which can enable developers to create leaner applications. In this article, we are looking at a situation where you consistently see memory rise until the server stops performing.
A common reason for high memoryOne reason for high memory that we see here in Support a lot is when you have debugging, tracing, or both enabled for your application. While you are developing your application, this is a necessity. By default, when you create your application in Visual Studio .NET, you will see the following attribute set in your Web.config file:
and/or
Also, when you do a final build of your application, make sure that you do this in "Release" mode, not "Debug" mode. Once you are in production, this should no longer be necessary. It can really slow down your performance and eat up your memory. Why? Well, setting this attribute means you change a few things about how you handle your application. First, batch compile will be disabled, even if it's specifically set in this compilation element. What this means is that you create an assembly for every page in your application so that you can break into it. These assemblies can be scattered somewhat randomly across your memory space, making it more and more difficult for you to find the contiguous space to allocate memory for when you need it. Second, the executionTimeout attribute (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/gngrfhttpruntimesection.asp) is set to a very high number, overriding the default of 90 seconds. This is fine when debugging, because you can't have the application time out while you patiently step through the code to find your blunders. However, it is a big risk in production. This means that should you have a rogue request for whatever reason, it will hold on to a thread and continue any detrimental behavior for days rather than just a minute and a half. Finally, you will be creating more files in your Temporary ASP.NET files folder, and the System.Diagnostics.DebuggableAttribute (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemdiagnostics.asp) gets added to all generated code, which can cause performance degradation. If you get nothing else from this article, I do hope you get this: leaving debugging enabled is bad. Also, remember that this can be set at the page level, so make sure that all of your pages are not setting this.Related Articles:More information on experiencing high memory leaks is provided by the following article from Microsoft’s Knowledge Base: http://support.microsoft.com/?id=893660Please note that the contents of any of the articles linked to this one are not authored nor maintained by Infragistics.