内存不足异常 - ASP.NET - IIS 7
问题出在内存管理上，因为我不断收到“内存不足异常”。 以下是我们遇到问题的场景：
请注意： 1. 站点/应用程序在 ASP.Net 中开发并上传到具有以下规格的服务器上： - Windows Server 2008 (R2) 标准版 - 英特尔至强[电子邮件受保护] 2.27GHz - 内存 = 8GB - 系统类型 = 64 位
该应用程序是基于事件管理的 Web 应用程序，其中要求包括在会话等中保存大量数据（在相关的情况下提及这一点）
应用程序/站点工作正常，直到我们：
- 直接在服务器上编辑文件
- 从存储库更新文件
- 复制/粘贴文件（我们通常不会使用此技术编辑代码）
- 请注意，上述所有内容仅在网站流量较高时才适用，即
- 当流量/访问量较低时，不会产生“内存不足”问题/错误
详细信息：
- 系统属性>高级>性能设置>高级选项卡
- 所有驱动器的分页文件总大小：16362 MB
在 web.config 中 有什么办法可以从根本上调试这个问题并找到解决方案。您能否提供我们可以进一步调查此问题的链接/帮助？
此致， 法鲁克
The problem is with Memory management because I keep receiving “Out of Memory exception”.
Here are the scenarios where we face the problem:
Please note:
1. The site/application is developed in ASP.Net and uploaded on a server with the following specs:
- Windows Server 2008 (R2) Standard
- Intel Xeon [email protected] 2.27GHz
- RAM = 8GB
- System Type = 64bit
The application is event management based web application where the requirements include saving huge amount of data in Sessions etc (mentioning this in case it is relevant)
The applications/site works fine until we:
- Edit a file directly on the server
- Update a file from repository
- Copy/Paste a file (we don’t usually edit code using this technique)
- Please note, all of the above hold true ONLY when the traffic to the site is high that is,
- The issue/error “Out of Memory” is not produced when the traffic/visits is low
Details of:
- System Properties > Advanced > Performance Settings > Advanced tab
- Total paging file size for all drives: 16362 MB
In web.config
Is there any way we can debug this problem to the core and find out a solution. Can you please provide links/help where we can further investigate this problem?
Best regards,
Farrukh
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
内存不足异常对于在内存中保留大量数据的同时出现周期性事务激增的应用程序来说很常见。然而，这个问题确实取决于您的应用程序和架构。以下是一些提示：
对你来说，GC 是问题的核心。就原因而言，这与每当应用程序超过 2-4 GB 时 Java 和 JVM 出现问题的原因相同。这就需要看看GC的实际过程了。
您有“老一代”和“年轻代”垃圾收集进程。当您的应用程序运行时，CLR 会尝试使您的内存空间保持井井有条。当 GC 标记和交换进程发生时，这些进程会强制所有线程暂停（阶段变化）。这里的问题是，根据代码的编写方式以及长期保留的内存量，您可能会遇到内存问题。
每当您按下运行时环境超过 4 GB 阈值时，您都会看到收集时间呈指数增长。当您遇到“停止世界”暂停（旧代 GC，所有内容都被清理）时，CLR 必须遍历整个堆并取消分配内存。根据您的应用程序，即使使用更多物理内存，16 GB 也可能会给您带来问题（Windows Server 2008 R2 - Enterprise 或 DataCenter 可以支持 2 TB）。即使您为其提供更多的物理内存，当您的完整 GC 命中时，您也可能会看到很长的收集时间。
理想情况下，我会执行以下操作：
获取更多物理内存（您永远不会希望将 600MB 的总物理内存分配给您的应用程序以避免内存不足错误，但您的缓冲区确实取决于您的负载和应用程序的能力来处理它...您可能需要更大的安全网来确保安全）。
一旦您拥有了物理内存，您就需要在对应用程序施加压力的同时运行 GC 日志。这将使您了解在哪里会看到性能指数级下降，以及在考虑堆大小（内存）时您的应用程序可以支持什么级别。您可能想找到一种方法来缩小 16GB 页面的大小。我确实知道 Microsoft 在 .Net 4.0 中对 GC 过程进行了一些实质性的改进，包括允许后台线程来维护 GC。这应该使您能够支持更大的堆（理论上）......但没有什么比应用程序上的实际测试更好的了。查看此链接以获取更多信息：
垃圾收集性能 (Asp.net 4.0) - 另外，因为我的链接有限。导航至“基础知识”页面，了解有关 ASP.Net 4.0 的新 GC 功能的一些精彩说明
（http://msdn.microsoft.com/en-us/library/ee787088.aspx#concurrent_garbage_collection）
希望这有帮助！
PS - 任何使用较少硬件的人都需要了解 ASP.NET 对 GC 线程的使用。如果您正在开发中运行像 Core Duo 这样的东西，您必须考虑 50% 的计算能力将用于 GC 优化。这意味着硬件（核心数量）是需要考虑的重要因素。如果您的数量超出了您的需要，那么理论上这个过程应该有助于提高性能。如果您的核心受到限制，请获取更好的硬件或使用旧版本的 ASP.Net，或者考虑关闭该功能（如果可能）。其次，如果延迟是一个问题，那么使用“超线程”确实也会对性能产生影响。您总是可以在“物理”核心上获得更好的性能……但这不会是 99.9% 的应用程序所关心的问题。
Out of Memory Exceptions are common with applications that see periodic transaction surges while keeping larger volumes of data in memory. This problem does, however, depend on your application and architecture. Below are a few pointers:
GC is the heart of your problem for you. In terms of why, it is the same reason Java and the JVM have issues whenever an application exceeds 2-4 GB. That requires a look at the actual process of GC.
You have "old generation" and "young generation" Garbage Collection processes. As you app runs the CLR tries to keep your memory space organized. These processes force all threads to pause (phase changes) when GC mark and swap processes occur. The problem here is, depending on how your code is written and the amount of memory you keep around for long periods, you can run into memory issues.
Any time you press a runtime environment to exceed the 4 GB threshold you will see exponential increases in collection times. When you hit the "stop the world" pause (the old gen GC where everything gets cleaned up) the CLR has to go through the entire heap and de-allocate memory. Based on your app, 16 GB may give you issues even with more physical memory (Windows Server 2008 R2 - Enterprise or DataCenter can support 2 TB). Even if you feed it more physical memory you may see LONG collection times when your full GC hits.
Ideally I would do the following:
Get more physical memory (you never want to come withing 600MB of your total physical memory allocated to your application to avoid out of memory errors, but your buffer does depend on your load and the application's ability to handle it ... you may want a larger safety net to be safe).
Once you have the physical memory you need run GC logs while stressing the app. This will give you an idea where you see exponential degradation in performance and what level your app can support when considering Heap size (Memory). You may want to find a way to get your 16GB page down to a smaller size. I do know with .Net 4.0 Microsoft has made some solid improvements to the GC process, including allowing a background thread to maintain GC. This should give you the ability to support larger heaps (in theory) ... but nothing beats real tests on the app. Check out this link for more info:
Garbage Collection Performance (Asp.net 4.0) - Also, as I am limited on links. Navigate to the Fundamentals page for some great explanations on new GC features of ASP.Net 4.0
(http://msdn.microsoft.com/en-us/library/ee787088.aspx#concurrent_garbage_collection)
Hope this helps!
PS - Anyone out there on lesser hardware will need to be aware of the ASP.NET use of the GC thread. If you are running something in development like a Core Duo you have to consider that 50% of your compute power will go to GC optimization. This means that Hardware (number of cores) is important to consider. If you have more than you need this process should theoretically help performance. If you are constrained on cores either get better hardware or use an older version of ASP.Net or consider turning the feature off (if possible). Second, if latency is a concern, using "hyper-threading" does have an impact on performance as well. You always get better performance on "physical" cores ... but that will not be a concern for 99.9% of the applications out there.
默认 2 GB。如果应用程序支持大地址空间（与 /LARGEADDRESSAWARE 链接），则它会获得 4 GB（请参阅 http://msdn.microsoft.com/en-us/library/aa366778.aspx）
它们仍然限制为 2 GB，因为许多应用程序依赖于指针的最高位为零。
2 GB by default. If the application is large address space aware (linked with /LARGEADDRESSAWARE), it gets 4 GB (see http://msdn.microsoft.com/en-us/library/aa366778.aspx)
They're still limited to 2 GB since many application depends on the top bit of pointers to be zero.