我试图找出网站的OutOfMemory的原因。这个网站有大约12,000个.aspx页面，最后一次崩溃我使用adplus捕获了一个内存转储。
经过一番调查后我发现了很多堆碎片，大约有100MB的Free块无法分配。挖掘较大的一个大对象堆是碎片化的，原因似乎是字符串实习，如[here] [1]
所述这可能是由网站中的页数引起的吗？因为他们都是编译的，所以他们坐在记忆中，通过查看转储他们被实习和PINNED，我认为这意味着他们会坚持一段时间。
我觉得这很奇怪，因为有很多网站有更多页面，但动态编译可以解释内存的增长。
还有哪些方法可以找到内存泄漏的原因？我试图在挂起模式下使用adplus捕获转储但是这会失败并且IIS工作进程会被回收。
答案 0 :(得分：0)
是否碎片化是其中一个原因，因为“找到”记忆会更加困难。
一些众所周知的线索：
在32位操作系统上，即使您的系统有更多，您的工作进程内存也不能超过2 GB。另一种选择是/ 3GB开关（boot.ini文件）。
当“Process \ Virtual Bytes”在虚拟地址空间限制的600 MB范围内（通常为2 GB）时，遇到OutOfMemoryException的可能性开始急剧增加，其次，测试显示“Process \ Virtual”字节“通常大于”Process \ Private Bytes“不超过600 MB
CLR按块分配和处理内存（内存为64 MB;））。这并不意味着它使用所有这些内存，这意味着在使用一个字节之前不会释放一个块，而是内存如何被分割。
当CLR无法分配内存（需要新块），并且它无法进行垃圾收集或寻呼部分内存时，OutOfMemoryException将在最佳情况下发生，否则服务器将被重载最坏的情况。
关于动态编译，这是真的，但最重要的是<compilation debug="false" /> / <deployment retail=”true”/>个开关。他们启用批量编译，这意味着一个DLL按目录（这是另一个点）而不是每个“页面”一个DLL导致虚拟空间碎片。
关于目录的一个DLL，即使是批量编译，你拥有的目录/子目录也多，你将拥有更多的DLL，以及你将拥有的更多零碎的虚拟地址空间。
就个人而言，我使用ANTS Memory Profiler来查找内存问题。
答案 1 :(得分：0)