多年来，我们一直在同一台虚拟机上托管 ASP.NET 4.5 应用程序和 SQL Server 2008R2 数据库，内存为 4GB。性能良好。
我们的应用程序是一个目录，我们大量使用 .NET 内存缓存来构建零件和相关数据的“工作集”。通常有 80,000-90,000 个缓存条目。
上周末我们升级到了 8GB 的 RAM，发现 ASP.NET 应用程序出现了奇怪的内存行为。
升级后，任务管理器告诉我们，我们只使用了 60% 的 RAM。SQL 响应非常快。但缓存条目增长到 15,000 个，然后又缩减到 7-8,000 个范围。GC 活动很多。就好像 ASP.NET 应用程序面临内存压力，但还有另外 3+ GB 的未使用 RAM。
为什么会这样？一切都是 64 位的。其他一切都没有改变。SQL 或应用程序池没有设置内存限制。应用程序没有回收，只是非常积极地修剪缓存。有什么想法吗？
答案1
根据微软的建议，标准 SASp.NET 进程是 32 位的，即使在 64 位主机上也是如此。如果没有充分的理由，请不要使用 64 位 - 它有缺点。如果需要 - 更改设置。Web 场设置 - 多个运行进程 - 是首选。
答案2
GC 活动并不总是与你拥有的内存量直接相关，但可能会受到应用程序池是在 32 位还是 64 位下运行的影响（来源）。如果您进行了大量对象分配，那么您将有大量的 GC 活动。
我们以 64 位运行所有进程（因为我们的一些数据处理需要高达 12GB 的 RAM），并且没有出现任何问题，也没有注意到性能有任何下降。确实，现在所有内存引用占用的内存是原来的两倍，但这可能会以运行更少的垃圾收集为代价，因此您永远不应该相信任何“这总是最好的选择”的规则。在性能方面，您总是希望自己衡量。
默认情况下，自 IIS 7 起，AppPool 已设置为在 64 位中运行。有关检查/修改 AppPool 以在 64 位中运行的说明可在此处找到（在“高级应用程序池设置”下）：
关于缓存，您是否考虑过使用进程外缓存，例如Windows 服务器 Appfabric以便它们可以跨主机使用，而不依赖于您的 IIS 应用程序池？如果内存压力位于专用应用程序中，您的网站很可能不会出现太多 GC 问题。
答案3
事实证明，SQL 占用的内存比我想象的要多得多。以前，当机器只有 4GB 时，我让 SQL 使用默认的最小和最大内存设置运行。它运行了两年多，运行良好。升级到 8GB RAM 后，它吞噬了所有内存，ASP.NET 也变得很吃力。昨晚我将最大内存设置为 5GB，今天早上一切都很顺利。我不想带来厄运，但我认为任务管理器的内存报告就像一张该死的地毯一样撒谎！我将在接下来的几天里摆弄 5GB 以寻找最佳点。