是否可以想象Process Explorer报告的虚拟大小可能导致OutOfMemory异常？

Question

我正在努力诊断我们的应用程序中的一系列OutOfMemoryException问题。这是一个内部32位（x86）OWIN托管的WebAPI，它在控制台应用程序中运行，并行地与一系列硬件组件对话。出于这个原因，它创建了大约20个库的实例，并且“虚拟大小”内存的急剧增加与创建这些实例时相匹配。

从Process Explorer和dotMemory的输出中，我们似乎没有在此应用程序中分配那么多实际内存：

从阅读许多，很多SO答案我认为我理解我们的问题要么是来自G0，G1，G2＆amp; LOH堆，或者我们可能会在Windows 7上运行的32位进程中遇到2GB可寻址内存限制。此应用程序分批工作，从硬件设备收集大量数据，在内存中创建集合以聚合该数据到一个对象，然后保存它以供客户端应用程序检索。这个活动是dotMemory visual中峰值的原因，但是这些数据结构并不是很大，我认为dotMemory图表显示了这个。

看着这些堆已经显示它们的规模很少超过10-15MB，而且我没有看到很多证据表明LOH增长太大或严重碎片化。我真的在努力学习如何更好地理解这里发生的事情。

所以我的问题是双重的：

1. 可以想象我们可以达到虚拟内存的2GB限制，这是造成这些内存异常的原因吗？

2. 如果 是可能的原因那么我是否正确地认为64位构建会绕过它？

我们正在探索迁移到64位版本，但这需要更新我们使用的一些低级库也是64位。这肯定是我们最终会探索的选择（如果不是更早），但我们会在投入所需时间之前更好地了解这种情况。

设置LARGEADDRESSFLAG

后更新

根据建议我在二进制文件上设置了该标志，并且有趣地看到虚拟大小立即跳转到接近3GB。我不知道我是否应该对此感到震惊？！



我将在接下来的几个小时内使用此配置监控应用程序。

Answer 1

就我而言，@ TosmasWeller提供的建议确实是正确的，并且能够识别大地址＆＃34; flag允许此应用程序运行几天而不会抛出内存异常。