【发布时间】：2009-03-07 09:15:24
【问题描述】：
我们看到大量虚拟内存碎片和内存不足错误，然后达到了 3GB 的限制。
编译调试在 web.config 中设置为 true，但我从我问的每个人那里得到了不同的答案，调试设置为 true 是否会导致每个 aspx 编译到 ram 的随机区域，从而使该 ram 碎片化并最终导致内存不足有问题吗？
【问题讨论】：
标签： asp.net web-config
【发布时间】：2009-03-07 09:15:24
【问题描述】：
Scott Guthrie（ASP.NET 开发团队的经理）有一个interesting post about it。
你不应该离开debug="true"的最重要的一点是：
- ASP.NET 页面的编译需要更长的时间（因为某些批处理优化被禁用）
- 代码执行速度可能会变慢（因为启用了一些额外的调试路径）
- 运行时在应用程序中使用更多内存
- 从 WebResources.axd 处理程序下载的脚本和图像不会被浏览器缓存，导致之间的请求更多 客户端和服务器
他还提到了 machine.config 中的标志 <deployment retail=”true”/>，它允许全局覆盖在机器上运行的所有应用程序的 debug="true" 标志（例如，在生产服务器上）。
更新：使用debug="true" 部署网络应用程序仍然很糟糕，您可以在Scott Hanselman's recent blog post 中阅读：
这就是 debug="true" 不好的原因。说真的，我们不是在开玩笑。
- 覆盖请求执行超时，使其有效地无限
- 禁用页面和 JIT 编译器优化
- 在 1.1 中，导致 CLR 过度使用内存来跟踪调试信息
- 在 1.1 中，关闭动态页面的批量编译，导致每页 1 个程序集。
- 对于 VB.NET 代码，会导致过度使用 WeakReferences（用于编辑和继续支持）。
重要提示：与有时所相信的相反，设置 一个元素中的retail="true" 不是直接的解毒剂 有 debug="true"！
【讨论】：
-
我公司的标准政策是所有生产网络服务器都在 machine.config 中设置了部署标签。这样可以省去很多麻烦。
除非您确实需要调试应用程序，否则应在 web.config 中将调试标志设置为 false。
在调试模式下运行可能会在一定程度上增加内存使用量，但问题不太可能像您所说的那样严重。但是，您应该将其设置为 false 以消除它的影响，看看您是否可以注意到任何改进。
在调试模式下运行时，垃圾收集的工作方式不同。变量的生命周期从它的实际使用扩展到变量的范围（以便能够在调试器中显示值）。这使得一些对象在被垃圾回收之前的寿命更长。
在调试模式下编译时编译器不会对代码进行优化，还额外增加了一些nop指令，使每一行代码至少有一条可以放置断点的指令。
在调试模式下抛出异常需要相当长的时间。 （但是，通常代码不应该经常抛出异常。）
【讨论】：
它绝对会影响内存，只需查看一些性能计数器并与两种配置进行比较即可。
如果您的站点有很多文件，我会更关心 asp.net 临时文件夹中的磁盘 io。
几个问题...
- 您的 App_Code 中有很多文件吗？
- 您是允许网站更新还是发布它？
- 如果是，是网站经常更新还是有部署流程？
- 什么是硬件配置？
为什么不使用多种配置？
Web.Debug.Config - 打开调试 Web.UAT.Config - 无论你喜欢什么 Web.Release.Config - 关闭调试
这样您可以最大限度地减少回归配置错误，例如开发人员使用 debug="true" 检查 web.config
【讨论】：
AFAIK "debug = true" 不会导致您提到的情况。
我在使用动态创建图像的 ASP.NET 应用程序时遇到了同样的问题。
所以我认为您对未处置的资源有疑问。
如果您将带有代码隐藏文件的 aspx 文件部署到服务器。当请求到达一个aspx时，它将被编译一次。然后它将被存储到缓存中，直到文件发生变化。
【讨论】：
在生产系统上始终设置 Debug=false。正如标志所暗示的，它应该只在调试开发系统时设置为 true。
这个标志和你的内存碎片问题无关。
【讨论】：