我一直在调查IIS6上运行的生产经典ASP网站的问题，这似乎指示内存碎片。
其中一个如何改善这个来自Stackoverflow的build议： 我怎么能find为什么一些经典的ASP页面随机采取真正的长时间执行？ 。 它build议翻转站点的global.asa文件中的设置以打开低碎片堆 （LFH）。
下面的代码（附带DLL的注册版本）做了诀窍。
Set LFHObj=CreateObject("TURNONLFH.ObjTurnOnLFH") LFHObj.TurnOnLFH() application("TurnOnLFHResult")=CStr(LFHObj.TurnOnLFHResult) （真的代码不是那么重要的问题）。
一个链接的post的作者报告了这个问题的一个看似神奇的解决scheme，并多读一点，我发现这个设置在Windows Server 2008上默认启用。
所以，这自然让我有点担心：
我怀疑上面的答案是相同的（如果有的话）。
显然，我们正在非生产环境中进行testing，并进行一系列度量和比较来判断它是否对我们有帮助。 但是除此之外，我只是想了解是否有任何技术上的原因，我们应该这样做，或者有什么需要注意的问题。
在Windows中，当编写不好的应用程序以低效的方式分配内存时，堆会碎片化，从而导致其堆被留在碎片状态。 当一个应用程序的堆完全碎片化时，它不能再进行内存分配，因为堆中没有足够大的内存块来满足请求。 这一切都在一点点碎片。 即使所有这些小片段的大小总和加起来足以满足内存分配。
强调写得不好的应用程序。
Sysinternal的VMMap非常适合查看进程的地址空间并检查这种碎片问题。
请注意，ASLR也是在2008年推出的，这在一定程度上加剧了这个碎片化问题。 我想这对于在该操作系统中默认启用LFH的决定有一些影响。 此外，LFH政策往往需要更多的内存AFAIK，这可能是在2003年代比2008年更多的问题。
为了得到一个更明确的答案，就是为什么微软决定在2008年改变这个政策，你可能不得不问微软的那些工程师。