为什么 .NET 在物理量 >95% 时不将未使用的内存释放回 OS？
Why doesn't .NET release unused memory back to OS when physical >95%?
我们正在测试一个 4 进程 WCF IIS 应用程序（x3 发行版）的内存稳定性（泄漏），方法是像负载平衡器一样每隔约 1 秒对它执行一次 ping 操作。如果服务器上没有 运行，它可以正常运行 >12 小时。
但是，如果我们有意减少总可用内存（修复页面、减少物理内存、启动其他应用程序）并将 物理 内存使用率推至 97% 并保留在那里持续 5 分钟或更长时间，通常 Windows 会检测到情况并关闭其中一个进程。请注意，如果 total 内存被推送到 97%（通过使用固定页面文件），它也会失败。
但是，使用 RedGate 工具分析其中一个幸存进程的内存占用情况表明：
由于请求只是一个稳定的 ping，似乎没有实际理由让 .NET 在服务器不足时保留 269MB 空闲内存。大约 50% 的 IIS 进程似乎处于此状态 (~1.8GB)。
该应用程序是针对 .NET 4.0 编译的，gcServer 为真。 IIS Gate 检查设置为 0% (minFreeMemoryPercentageToActivateService="0")，尽管我们可能会在生产中将其设置为 2%。
服务器是 2008 R2，~4GB 物理 4GB 固定页面，先用 4.0 再用 4.5.1 测试（没关系）。
有一个 answer to a similar question by @atanamir 声称：
".NET will free its heap back to the OS once you're running low on
physical memory."
有人知道该声明的参考资料吗？它可以是特定于版本的吗？
参考文献：
- .NET Free memory usage (how to prevent overallocation / release memory to the OS)
- When is memory, allocated by .NET process, released back to Windows
阿塔纳米尔给出的信息可以在这个MSDN page.
上找到
Garbage collection occurs when one of the following conditions is true:
The system has low physical memory.
The memory that is used by allocated objects on the managed heap surpasses an acceptable threshold. This threshold is continuously adjusted as the process runs.
The GC.Collect method is called. In almost all cases, you do not have to call this method, because the garbage collector runs continuously. This method is primarily used for unique situations and testing.
这并不能完全回答您提出的问题（为什么），但它应该是实现您想要做的事情的一种方式。
.NET Framework 4.5 有一些新东西 - source
Once a site is running, its use of the garbage-collector (GC) heap can be a significant factor in its memory consumption. Like any garbage collector, the .NET Framework GC makes tradeoffs between CPU time (frequency and significance of collections) and memory consumption (extra space that is used for new, freed, or free-able objects). For previous releases, we have provided guidance on how to configure the GC to achieve the right balance.
For the .NET Framework 4.5, instead of multiple standalone settings, a workload-defined configuration setting is available that enables all of the previously recommended GC settings as well as new tuning that delivers additional performance for the per-site working set. For example, there is no need to set gcServer, gcConcurrent, etc.
他们还 here 声明：
Tuning GC for high-density Web hosting: GC can impact a site’s memory consumption, but it can be tuned to enable better performance. You can tune or configure GC for better CPU performance (slow down frequency of collections) or lower memory consumption (that is, more frequent collections to free up memory sooner) […] in order to achieve smaller memory consumption (working set) per site
要启用 GC 内存调整，请将以下设置添加到 Windows\Microsoft.NET\Framework\v4.0.30319\aspnet.config 文件和 Windows\Microsoft.[=31= .0.30319\aspnet.配置文件：
<configuration>
<!-- ... -->
<runtime>
<performanceScenario value="HighDensityWebHosting" />
<!-- ... -->
基本上，根据我所做的测试，我看到它会消耗更多 CPU、更少的内存，并使 GC 在清理和内存释放过程方面更加积极。
我们在我们的基础架构（IIS 7.5、新的 4.5 框架）中测试了此设置，结果令人印象深刻。导致内存不足异常的高内存使用率不再是问题。
希望对您有所帮助。
我们正在测试一个 4 进程 WCF IIS 应用程序（x3 发行版）的内存稳定性（泄漏），方法是像负载平衡器一样每隔约 1 秒对它执行一次 ping 操作。如果服务器上没有 运行，它可以正常运行 >12 小时。
但是，如果我们有意减少总可用内存（修复页面、减少物理内存、启动其他应用程序）并将 物理 内存使用率推至 97% 并保留在那里持续 5 分钟或更长时间，通常 Windows 会检测到情况并关闭其中一个进程。请注意，如果 total 内存被推送到 97%（通过使用固定页面文件），它也会失败。
但是，使用 RedGate 工具分析其中一个幸存进程的内存占用情况表明：
由于请求只是一个稳定的 ping，似乎没有实际理由让 .NET 在服务器不足时保留 269MB 空闲内存。大约 50% 的 IIS 进程似乎处于此状态 (~1.8GB)。
该应用程序是针对 .NET 4.0 编译的，gcServer 为真。 IIS Gate 检查设置为 0% (minFreeMemoryPercentageToActivateService="0")，尽管我们可能会在生产中将其设置为 2%。
服务器是 2008 R2，~4GB 物理 4GB 固定页面，先用 4.0 再用 4.5.1 测试（没关系）。
有一个 answer to a similar question by @atanamir 声称：
".NET will free its heap back to the OS once you're running low on physical memory."
有人知道该声明的参考资料吗？它可以是特定于版本的吗？
参考文献：
- .NET Free memory usage (how to prevent overallocation / release memory to the OS)
- When is memory, allocated by .NET process, released back to Windows
阿塔纳米尔给出的信息可以在这个MSDN page.
上找到Garbage collection occurs when one of the following conditions is true:
The system has low physical memory.
The memory that is used by allocated objects on the managed heap surpasses an acceptable threshold. This threshold is continuously adjusted as the process runs.
The GC.Collect method is called. In almost all cases, you do not have to call this method, because the garbage collector runs continuously. This method is primarily used for unique situations and testing.
这并不能完全回答您提出的问题（为什么），但它应该是实现您想要做的事情的一种方式。
.NET Framework 4.5 有一些新东西 - source
Once a site is running, its use of the garbage-collector (GC) heap can be a significant factor in its memory consumption. Like any garbage collector, the .NET Framework GC makes tradeoffs between CPU time (frequency and significance of collections) and memory consumption (extra space that is used for new, freed, or free-able objects). For previous releases, we have provided guidance on how to configure the GC to achieve the right balance. For the .NET Framework 4.5, instead of multiple standalone settings, a workload-defined configuration setting is available that enables all of the previously recommended GC settings as well as new tuning that delivers additional performance for the per-site working set. For example, there is no need to set gcServer, gcConcurrent, etc.
他们还 here 声明：
Tuning GC for high-density Web hosting: GC can impact a site’s memory consumption, but it can be tuned to enable better performance. You can tune or configure GC for better CPU performance (slow down frequency of collections) or lower memory consumption (that is, more frequent collections to free up memory sooner) […] in order to achieve smaller memory consumption (working set) per site
要启用 GC 内存调整，请将以下设置添加到 Windows\Microsoft.NET\Framework\v4.0.30319\aspnet.config 文件和 Windows\Microsoft.[=31= .0.30319\aspnet.配置文件：
<configuration>
<!-- ... -->
<runtime>
<performanceScenario value="HighDensityWebHosting" />
<!-- ... -->
基本上，根据我所做的测试，我看到它会消耗更多 CPU、更少的内存，并使 GC 在清理和内存释放过程方面更加积极。 我们在我们的基础架构（IIS 7.5、新的 4.5 框架）中测试了此设置，结果令人印象深刻。导致内存不足异常的高内存使用率不再是问题。
希望对您有所帮助。