We're seeing lots of virtual memory fragmentation and out of memory errors and then it hits the 3GB limit.
The compilation debug is set to true in the web.config but I get different answers from everyone i ask, does debug set to true cause each aspx to compile into random areas of ram thus fragmenting that ram and eventually causing out of memory problems?
AFAIK "debug = true" not cause the situation you mentioned.
I had faced same problem with an ASP.NET application that created images on the fly.
so I think you have a problem with not disposed resources.
If you deploy your aspx files with code-behind files to server. It will be compiled once when the request comes to an aspx. then it will be stored to the cache until the file changes.
The debug flag should be set to false in web.config, unless you actually need to debug the application.
Running in debug mode can increase the memory usage somewhat, but it's not likely case as severe problems as you are talking about. However, you should set it to false to elliminate the effect that it has, and see if you can notice any improvement.
When run in debug mode, the garbage collection works differently. The life time of variables is expanded from it's actual usage to the scope of the variable (to be able to show the value in the debugger). This makes some objects live longer before they are garbage collected.
The compiler doesn't optimize the code when compiling in debug mode, and also some extra nop instructions are added so that each code line has at least one instruction where a break point can be placed.
Throwing an exception takes considerably longer in debug mode. (However, normally the code should not throw exceptions that often.)
Scott Guthrie (manager of the ASP.NET development team) has an interesting post about it.
The most important points why you should not leave debug="true" are:
He also mentions the flag <deployment retail=”true”/> in machine.config, which allows to globally override the debug="true" flag of all applications running on a machine (e.g. on a production server).
Update: deploying web apps with debug="true" is still bad, as you can read in Scott Hanselman's recent blog post:
Here's why debug="true" is bad. Seriously, we're not kidding.
An important note: Contrary to what is sometimes believed, setting retail="true" in a element is not a direct antidote to having debug="true"!
On production systems always set Debug=false. As the flag suggests it should only be set to true when debugging a development system.
This flag has nothing to do with your memory fragmentation problem.
It absolutely could affect memory, just take a look at some of the perfmon counters and run a comparison with both configurations.
If your site has a lot of files I would be more concerned with disk io in the asp.net temp folder.
Couple Questions...
Why not utilize multiple configurations?
Web.Debug.Config - Have debugging turned on Web.UAT.Config - Whatever your preference Web.Release.Config - Have Debugging turned off
This way you can minimize regression configuration errors like a developer checking a web.config in with debug="true"