ASP.Net：查找 OutOfMemoryExpcetions 的原因
我试图找出网站内存不足的原因。该网站有大约 12,000 个 .aspx 页面，上次崩溃时我使用 adplus 捕获了内存转储。
经过一番调查，我发现有很多堆碎片，大约有 100MB 的空闲块无法分配。深入挖掘，其中一个大对象堆是碎片化的，原因似乎是字符串驻留，如[此处][1]所述，
这是否是由站点中的页面数量引起的？由于它们都已编译，因此它们位于内存中，通过查看转储，它们被拘留并固定，我认为这意味着它们会保留一段时间。
我觉得这很奇怪，因为有很多网站都有更多页面，但动态编译可以解释内存的增长。
还有哪些方法可以查找内存泄漏的原因？我尝试在挂起模式下使用 adplus 捕获转储，但失败并且 IIS 工作进程被回收。
[1]： • 大对象堆碎片
I trying to track down the cause of an OutOfMemory for a website. This site has ~12,000 .aspx pages and the last time it crashed I captured a memory dump using adplus.
After some investigation I found a lot of heap fragmentation, there are around 100MB of Free blocks which can't be assigned. Digging deeper one of the Large Object Heaps is fragmented and the causes seems to be String interning as described [here][1]
Could this be caused by the number of pages in the site? As they are all compiled they sit in memory and by looking at the dump they are interned and PINNED which I think means they stick around for a while.
I would find this odd as there are many sites with more pages, but dynamic compilation could account for the growth in memory.
What other methods are there for finding the cause of the memory leak? I have tried to capture a dump using adplus in hang mode but this fails and the IIS worker process get recycled.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
是的，碎片是原因之一，因为“找到”内存会更加困难。
一些众所周知的线索：
在 32 位操作系统上，即使您的系统有更多内存，您的工作进程内存也不能超过 2 GB。另一种选择是 /3GB 开关（boot.ini 文件）。
当“Process\Virtual Bytes”在虚拟地址空间限制（通常为 2 GB）的 600 MB 以内时，遇到 OutOfMemoryException 的可能性开始急剧增加，其次，测试表明“Process\Virtual Bytes”在通常比“Process\Private Bytes”大不超过 600 MB
CLR 按块分配和处理内存（内存中的 64 MB； ））。这并不意味着它会使用所有这些内存，而是意味着在使用一个字节之前不会释放一个块，这就是内存变得碎片化的原因。
当 CLR 无法分配内存（需要新块），并且无法垃圾收集或分页某些内存时，在最好的情况下会发生 OutOfMemoryException，在最坏的情况下服务器将过载.
关于动态编译，确实如此，但最重要的是
按目录大约一个 DLL，即使批量编译，您将拥有更多的目录/子目录，您将拥有更多的 DLL，并且您将拥有更多零散的虚拟地址空间。
就我个人而言，我使用 ANTS Memory Profiler 来查找内存问题。
Yep fragmentation is one of the reason because it will be more difficult to 'find' memory.
Some very known clues :
On a 32bit OS, your worker process can't exceed 2 GB in memory even if your system have more. An alternative is the /3GB switch (boot.ini file).
The likelihood of experiencing an OutOfMemoryException begins to increase dramatically when “Process\Virtual Bytes” is within 600 MB of the virtual address space limit (generally 2 GB), and secondly, tests have shown that “Process\Virtual Bytes” is often larger than “Process\Private Bytes” by no more than 600 MB
The CLR is allocating and handling the memory by blocks (64 MB from memory;)). It does not mean it use all this memory, it means one block will not be freed until one byte is used and it's how the memory become fragmented.
When the CLR can't allocate memory (new block needed), and it can't garbage collect or page some of the memory, OutOfMemoryException is going to happen in the best case or the server will be overloaded in the worst case.
About dynamic compilation, that's true but the most important is the
<compilation debug="false" />/<deployment retail=”true”/>switches. They turn on batch compilation which mean one DLL by directory (this is another point) and not one DLL per 'page' which cause virtual space fragmentation.About one DLL by directory, even with batch compilation, more directories/sub-directories you have, more DLL you will have and more fragmented virtual address space you will have.
Personally, I use ANTS Memory Profiler to find memory issues.
这里有一篇非常棒的博客，作者是 Tess Ferrandez讨论开发 ASP.NET 应用程序时的内存问题和其他类型的调试问题。
一个 帖子 特别引导您完成教程以查看是否存在泄漏。它使用令人讨厌的 WinDBG，但她解释了所有命令，以便您可以清楚地了解已使用的内存，并准确地向您显示哪些对象填充了所有空间。
我曾多次使用她的网站来诊断内存泄漏和其他与性能相关的问题。
我还使用过诸如 之类的工具DebugDiag 帮助捕获与内存相关的问题，并使用其内置的诊断工具来帮助查找问题。
There is a really good blog here by Tess Ferrandez that talks about memory issues and other types of debugging issues while developing ASP.NET applications.
One post in particular walks you through a tutorial to see if you have a leak. Its uses the nasty WinDBG, but she explains all the commands so you can get a clear picture of your used memory and it shows you exactly which objects are filling all the space.
I have used her site many times to diagnose memory leaks and other performance related problems.
I have also used tools like DebugDiag to help capture memory related issues and used its built in diagnostic tools to help find the problems.