我们在混合的传统ASP / .NET网站上遇到了内存不足的问题已经有一段时间了。 基本上，我们看到几个不同的情况：
崩溃有EventID：1009,1011和1013。
在这两种情况下，ASP都会在我们的应用程序日志中报告内存不足消息
如果我们真的“内存不足”，为什么应用程序中的用户仍然可以工作，新用户甚至不能login？ 这不是说没有任何要求可以提供吗？
显然，IIS仍然可以处理一些请求 – 所以答案可能是取决于具体的请求。 也许一个比另一个更“昂贵”？
无论如何，我的最终问题是 – 应用程序池在什么时候说足够了，我必须回收？
我们运行DebugDiag，看到一些超过90％甚至100％碎片的堆，所以只有当碎片高和没有更多的堆空间时，才会发生回收 。
这是一个稍微有些主观的问题，但是我希望能够得到一些关于这个门槛的信息！
谢谢。
除非工作进程违反了您configuration的回收标准之一（虚拟字节限制看起来像是一个好的回合标准？），或者无法回应Ping，它不会被回收。
应用程序（ISAPI）可以报告自己不健康，这会触发回收，但是这种情况发生在相当狭窄的条件下。
你的应用程序在运行时基本上是分段存储的，OOM反映了这一点 – 没有空闲的连续的 ，未分配的内存可用于新的分配; 他们失败了。
基于描述的选项是：
修复分配模式
将应用程序的各个部分分离成单独的应用程序池（例如，与ASP分开运行.Net） – 并非所有的应用程序都可以通过这种方式分解，但是对于那些可以轻松取胜的应用程序而言。 两个应用程序池= 2（或更多）工作进程=每个工作进程地址空间2GB
实现一个虚拟的字节数限制来回收应用程序池，当它变得太大
实施每日回收，以防止应用程序到达整个内存空间分散的地步
如果您的应用程序是无状态的，请尝试networking园艺; 增加最大＃工作进程为了避免失败更长时间
在64位系统上以32位应用程序运行; 4GB提供给工作进程。
从本质上讲，如果（不pipe）堆是否变得超级碎片化，那么在那个时候你就处于一个死亡螺旋状，你需要一个新的工作进程。
IIS没有内置的安全带，所以在到达这一点之前，为您的stream程实施回收限制 – 或者只是说“忘记了，我要走64位！ 可能是解决scheme。