ASP.NET没有看到RAM升级？

几年来，我们在4GB内存的同一虚拟机上托pipe了一个ASP.NET 4.5应用程序，作为SQL Server 2008R2数据库。 performance很好。

我们的应用程序是一个目录，我们大量使用.NET内存caching来build立零件和相关数据的“工作集”。 80,000-90,000个高速caching条目是典型的。

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

升级后，任务pipe理器告诉我们，我们只使用60％的RAM。 SQL非常敏感。但是caching条目增长到15,000，然后修剪回7-8,000范围。有很多GC活动。就好像ASP.NET应用程序在内存压力下一样，但是还有另外3个GB的未使用的RAM。

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

即使在64位主机上，标准SASp.NET进程也是按照微软推荐的32位。不要使用64位的好理由 – 它有缺点。如果您需要 – 更改设置。 Web场设置 – 多个运行stream程 – 是首选。

GC活动并不总是直接与您拥有多less内存相关，但可能受到应用程序池是以32位还是64位（源）运行的影响。如果你正在做大量的对象分配，那么你将有很多的GC活动。

我们以64位的方式运行我们的所有进程（因为我们的一些数据处理将我们的进程占用了12GB的RAM），并且没有问题，或者注意到性能变慢。确实，所有的内存引用现在占用了两倍的内存，但是这可能会减less垃圾回收，所以你绝对不应该相信任何规则：“这总是最好的事情”。在表演的情况下，你总是想自己衡量一下。

默认情况下，由于IIS 7 AppPools已经设置为以64位运行。在这里可以find关于检查/修改AppPool运行在64位的指令（在高级应用程序池设置下）：

应用程序池设置

关于caching，您是否考虑过使用进程外高速caching（如Windows Server Appfabric），以便它们可以跨主机使用并且不依赖于您的IIS应用程序池？如果内存压力位于专用应用程序中，您的网站很可能会有较less的GC问题。

事实certificate，SQL比我想像的要多得多。在机器只有4GB之前，我让SQL运行默认的最小和最大内存设置。它运行了两年以上。升级到8GB内存后，它吞噬了一切，ASP.NET WAS饿死了。我昨天把最大内存设置为5GB，今天早上的事情很好，很安静。我不想这样做，但我认为任务经理的记忆报告就像一个地毯！在接下来的几天里，我将要用5GB的硬盘来寻找最佳位置。