内存不足异常 - ASP.NET - IIS 7

Question

问题出在内存管理上,因为我一直收到"Out of Memory exception".以下是我们遇到问题的情景:

请注意:1.站点/应用程序是在ASP.Net中开发的,并上传到具有以下规格的服务器上: - Windows Server 2008(R2)标准版 - Intel Xeon L5520@2.27GHz 2.27GHz - RAM = 8GB - 系统类型= 64位

1. 该应用程序是基于事件管理的Web应用程序,其中的要求包括在Sessions等中保存大量数据(如果相关,请提及此内容)

2. 应用程序/站点正常工作,直到我们:

   • 直接在服务器上编辑文件
   • 从存储库更新文件
   • 复制/粘贴文件(我们通常不使用此技术编辑代码)
   • 请注意,以上所有情况仅适用于网站流量高的情况,
   • 当流量/访问量较低时,不会产生问题/错误"Out of Memory"

3. 的细节:

   • 系统属性>高级>性能设置>高级选项卡
   • 所有驱动器的总页面文件大小:16362 MB

4. 在web.config中有什么方法可以将这个问题调试到核心并找到解决方案.您能否提供我们可以进一步调查此问题的链接/帮助？

最好的问候,Farrukh

Answer 1

内存不足异常对于看到周期性事务激增同时在内存中保留大量数据的应用程序很常见.但是,此问题取决于您的应用程序和体系结构.以下是一些指示:

1. 硬件 - 你有Xeon 5500(Intel Nehalem芯片).这些都非常善于处理内存.你应该在这里好.
2. 操作系统 - Windows Server 2008 R2 - 作为一个操作系统,该系统将为您处理足够的内存(您在这里很好,请参阅功能链接:Windows的内存限制)
3. 物理内存 - 您说服务器上有8 GB吗？请注意,您的应用程序允许16 GB.有一个问题.如果您的应用请求的内存超过实际可用内存,您将看到错误.但这不是你唯一关心的问题......
4. CLR/GC限制 - 您的应用程序的"页面文件大小"为16 GB.这可能是你的问题.

GC是您的问题的核心.就原因而言,只要应用程序超过2-4 GB,Java和JVM就会出现问题.这需要查看GC的实际过程.

你有"老一代"和"年轻一代"的垃圾收集流程.当你运行app时,CLR会尝试保持你的内存空间有条理.当GC标记和交换过程发生时,这些进程会强制所有线程暂停(阶段更改).这里的问题是,根据代码的编写方式和长时间保存的内存量,可能会遇到内存问题.

每当您按运行时环境超过4 GB阈值时,您将看到收集时间呈指数级增长.当您点击"停止世界"暂停时(旧的GC将清除所有内容),CLR必须遍历整个堆并取消分配内存.根据您的应用程序,即使具有更多物理内存,16 GB也可能会给您带来问题(Windows Server 2008 R2 - Enterprise或DataCenter可支持2 TB).即使您为其提供更多物理内存,当您的完整GC命中时,您可能会看到LONG收集时间.

理想情况下,我会做以下事情:

1. 获得更多物理内存(您永远不希望为您的应用程序分配600MB的总物理内存,以避免内存不足错误,但您的缓冲区确实取决于您的负载和应用程序处理它的能力......您可能需要更大的安全网是安全的).

2. 获得物理内存后,您需要在强调应用程序的同时运行GC日志.这将让您了解在考虑堆大小(内存)时,您会看到性能呈指数级下降以及应用可支持的级别.您可能希望找到一种方法将16GB页面缩小到更小的尺寸.我确实知道.Net 4.0 Microsoft已经对GC进程做了一些可靠的改进,包括允许后台线程来维护GC.这应该让你能够支持更大的堆(理论上)......但没有什么比应用程序的真正测试更好.查看此链接以获取更多信息:

垃圾收集性能(Asp.net 4.0) - 另外,由于我的链接有限.导航到Fundamentals页面,了解有关ASP.Net 4.0的新GC功能的一些很好的解释(http://msdn.microsoft.com/en-us/library/ee787088.aspx#concurrent_garbage_collection)

希望这可以帮助!

PS - 任何有较小硬件的人都需要了解ASP.NET线程的使用.如果您正在开发像Core Duo这样的开发项目,则必须考虑50%的计算能力将用于GC优化.这意味着要考虑硬件(核心数).如果你有超过你需要的这个过程理论上应该有助于提高性能.如果您受到核心限制,请获得更好的硬件或使用旧版本的ASP.Net或考虑关闭该功能(如果可能).其次,如果延迟是一个问题,使用"超线程"确实也会对性能产生影响.你总是在"物理"核心上获得更好的性能......但对于99.9%的应用程序来说,这不会是一个问题.