ASP.NET没有看到内存升级？

Question

几年来，我们在一个4GB内存中的Server 2008R2数据库的VM上托管了一个ASP.NET 4.5应用程序。表现很好。

我们的应用程序是一个目录，我们大量使用.NET内存缓存来构建一个“工作集”的部件和相关数据。80,000到90,000个缓存条目是典型的。

在过去的周末，我们升级到了8GB内存，我们看到了ASP.NET应用程序的奇怪的内存行为。

升级之后，任务管理器告诉我们，我们只使用了60%的RAM。SQL响应性很强。但是缓存条目增加到15,000，然后被裁剪回7-8,000范围。有大量的GC活动。就好像ASP.NET应用程序正处于内存压力之下，还有另一个3+ GB的未使用内存。

为什么会这样？一切都是64位。其他的一切都没有改变。SQL或Application没有设置内存限制。应用程序不是回收，只是非常积极地修剪缓存。有什么想法吗？

Answer 1

事实证明，SQL占用的内存比我想象的要多。以前，当机器只有4GB时，我让SQL使用默认的min和max内存设置运行。在two+的几年里，它运行得很好。升级到8GB内存后，它吞食了所有内存，ASP.NET被饿死了。我昨晚把最大内存设置为5GB，今天早上一切都很好。我不想把它搞砸，但我认为任务经理的记忆报告就像一块该死的地毯！在接下来的几天里，我将用5GB的容量来寻找这个甜蜜的地方。

Answer 2

根据微软的建议，标准SASp.NET进程是32位，甚至在64位主机上也是如此。不要使用64位明智的理由-它有缺点。如果你需要-改变设置。Web场设置-多个运行进程-优先考虑。

Answer 3

GC活动并不总是与您拥有多少内存直接相关，但是会受到应用程序池在32位还是64位(来源)中运行的影响。如果您正在进行大量的对象分配，那么您将有大量的GC活动。

我们以64位的方式运行我们的所有进程(因为我们的一些数据处理需要高达12 or的RAM)，并且没有问题，或者注意到性能更慢。诚然，您的所有内存引用现在占用的内存是以前的两倍，但这可能以减少垃圾收集为代价，因此您不应该相信任何说“这永远是最好的事情”的规则。在表现的情况下，你总是想自己衡量事情。

默认情况下，自IIS7以来，AppPools已设置为在64位内运行。有关检查/修改AppPool以在64位中运行的说明可以在这里找到(在高级应用程序池设置下)：

关于缓存，您是否考虑过使用进程外缓存(如Windows Server Appfabric )，以便它们可以跨主机使用，而不依赖于IIS？如果内存压力位于专用应用程序中，则您的网站最有可能出现较少的GC问题。