Memory VMMap-为什么一个exe的提交内存为13.4GB？工作集只有1.7GB

所以我的问题是关于这个似乎正在吞噬我的服务器RAM的exe。它是Windows Server 2008 R2。重新启动似乎没有帮助，因为提交大小将保持在13GB左右。我注意到了这一点，因为由于程序的性能问题，供应商需要更多的RAM

最让我担心的是，这个程序看起来并没有实际使用它要求的所有RAM。我还没有看到私有工作集内存超过4GB。当用户抱怨速度慢和工作站被锁定时，我观察了服务器，但它仍然没有使用所有提交的内存

这是内存泄漏吗？这个exe到底是怎么回事，为什么它在实际需要时不使用所有提交的RAM

也就是说，我试图拿出具体的证据证明这是供应商的问题，因此供应商不再试图责怪我

这是一个虚拟机，作为一个故障排除步骤，我进入了虚拟机设置，确保内存分配正确，没有过度分配，并且我选中了内存资源分配的“无限”

谢谢你给我的建议或其他我可以尝试的疑难解答

---

分析工具：如果程序是用.NET编写的，请尝试Yourkit、ants、dotTrace等。如果是本机的，则通过Windows开发工具包（如UMDH）提供的调试工具是跟踪内存泄漏的好工具。尽管只有当您拥有程序及其依赖项的调试符号，最好是源代码时，才有意义

虽然内存泄漏有不同的罪魁祸首，但如果进程的内存消耗没有逐渐增加，在我看来，应用程序在达到这样的内存占用后的使用方式似乎不再泄漏内存。或者可能只是效率低下。或者出于某种原因，它确实需要13GB

现在，如果它将消耗内存直到耗尽计算机的资源，那么很可能是发生了泄漏

我还建议尝试找出是否有任何操作会引发泄漏。向供应商提供复制步骤会有所帮助

至于你原来的问题

工具书类

---

Windows中的进程永远不会“提交RAM”。它们提交虚拟地址空间
最让我担心的是它看起来不像 程序实际上正在使用它要求的所有RAM
程序不会“要求RAM”！它们请求提交的虚拟地址空间
Windows显示为“已提交”存储的不是RAM。它是虚拟内存可用性的保证，如果它实际被访问的话。如果曾经使用过，存储可能部分在RAM中，部分在页面文件中（假设您有一个页面文件）
“工作集（专用）”计数器显示进程提交的虚拟地址空间中大约有多少在RAM中。我之所以说“大约”，是因为提交的内存的一部分在进程工作集中一段时间后，可能会移动到修改过的页面列表中。从那里，它将被快速写入磁盘，并移动到备用页列表，从该列表中，RAM可以重新用于其他用途。（或者，如果它被带到进程中而未写入，则可以将其从工作集直接删除到备用列表中。）
这些列表在RAM中，但不在工作集中。如果进程在某个页面仍在这些列表中时引用该页面，则这是一个页面错误，但这是一个软页面错误，可以在不访问磁盘的情况下解决。它只是从列表中提取并放回流程工作集中
虚拟地址空间的“已提交”分配最多只消耗实际访问的RAM。一个程序在任何给定的运行中提交的内容超过实际使用的内容，这一点并不少见。。。虽然这个比例通常不是那么大！“最多”，因为操作系统内存管理器可能会从工作集中删除很久以前引用的私有页，以便为更频繁访问的内容释放RAM
如果此程序导致其他程序因“内存不足”或“内存不足”错误而失败，这将是放大页面文件的最佳时机。这些错误消息与提交限制有关，而与RAM无关。扩大页面文件将提高提交限制（从而消除错误消息），但由于该程序实际上没有使用那么多RAM，因此不会导致任何实际的页面文件IO
“提交”机制简单地保证，一旦操作系统告诉一个进程，“既然你成功地提交了这么多的虚拟内存，那么即使你在以后的运行中碰巧使用了所有虚拟内存，也可以保证操作系统有地方保存它。”但如果程序实际上没有引用所有虚拟内存，它不使用的部分不会占用任何重要的物理存储空间。不在RAM中，不在页面文件中，也不在任何地方
最让我担心的是它看起来不像 程序实际上正在使用它要求的所有RAM。我没有 然而，我们看到私有工作集内存超过4GB
它必须是32位，在这种情况下，WS永远不会超过4GB
请看我的答案。
在任务管理器中： 工作集不是内存使用的度量标准。提交指控是。 这就是为什么W8中的任务管理器图现在显示的是提交的而不是WS
WS是OS Balance Manager为一个或多个进程锁定的-RAM量。它不是负载
32位应用程序允许在RAM中锁定最大4GB。 64位可锁定最大8GB
在x64（Intel64/AMD64）上，32位应用程序的WS不相关，因为任何进程可用的地址空间都是256TB。 它仅受CPU和可用存储的限制
记忆