所以我的问题是关于这个似乎正在吃我的服务器的RAM的exe。它是Windows Server 2008 R2。重新启动似乎没有帮助，因为提交大小将保持或多或少13GB。这引起了我的注意，因为该程序的性能问题导致供应商需要更多内存。
令我担心的主要问题是它看起来并不像程序实际上正在使用它所要求的所有RAM。我还没有看到私有工作集内存超过4GB。当用户抱怨缓慢和锁定工作站时，我已经看过服务器，但仍然没有使用所有提交的内存。
这是内存泄漏吗？这个exe会发生什么导致这个问题，为什么它不是在实际需要时使用它所有提交的RAM？
也就是说，我试图提出具体的证据，证明这是供应商的问题，因此供应商不再试图责怪我。
这是一个虚拟机，作为故障排除步骤我进入虚拟机设置并确保内存分配正确，没有过度使用，我检查了“无限”内存资源分配。
感谢您提出的任何建议或任何其他疑难解答！
Windows中的进程不会“提交RAM”。他们提交虚拟地址空间。
令我担心的主要问题是它看起来并不像程序实际上正在使用它所要求的所有RAM。
程序不“要求RAM”！他们要求提交虚拟地址空间。
Windows显示为“已提交”的存储不是RAM。如果实际访问它，它是虚拟内存可用性的保证。如果它曾经使用过，存储可能部分在RAM中，部分在页面文件中（假设你有一个页面文件）。
“工作集（私有）”计数器大约显示进程提交的虚拟地址空间在RAM中的大小。我说“大约”，因为在过程工作集一段时间之后，已提交内存的一部分可能会被移动到修改后的页面列表中。从那里它将被快速写入磁盘并移动到备用页面列表，RAM可以从中重新用于其他内容。 （或者，如果它被带入进程并且没有写入，则可以将其从工作集直接删除到备用列表。）
这些列表在RAM中，但它们不在工作集中。如果进程在页面仍然位于其中一个列表时引用页面，那就是页面错误，但这是一个软页面错误，无需转到磁盘即可解决。它只是从列表中取出并放回到流程工作集中。
虚拟地址空间的“已提交”分配最多只会消耗实际访问的RAM。在任何给定的运行中，一个程序提交的实际数量超过实际使用数量并不罕见......虽然这个比例通常不是很大！ “最多”因为OS内存管理器可能会从工作集中删除很久以前引用的私有页面，以便为更频繁访问的内容释放RAM。
如果此程序导致其他程序因“内存不足”或“内存不足”错误而失败，那么这将是放大页面文件的绝佳时机。这些错误消息与提交限制有关，而不是RAM。扩大页面文件将提高提交限制（从而消除错误消息），但由于该程序实际上并没有使用那么多的RAM，因此不会再导致实际的页面文件IO！
“提交”机制只是保证一旦操作系统告诉进程“既然你已经成功提交了这个数量的虚拟内存，那么即使你碰巧使用它，操作系统仍然可以保留它，后来你的跑步。“但是如果程序实际上没有全部引用它，那么它不使用的部分不会在任何地方占用任何重要的物理存储。不在RAM中，不在页面文件中，不在任何地方。
分析工具：如果程序是用.NET编写的，请尝试使用Yourkit，ants，dotTrace等。如果是原生的，通过Windows开发工具包（如UMDH）提供的调试工具是跟踪内存泄漏的好工具。虽然只有程序及其依赖项的调试符号，最好是源代码，才对你有意义。
虽然内存泄漏有不同的罪魁祸首，但如果进程的内存消耗不会逐渐增加，那么在我看来，应用程序在达到内存占用后的使用方式不再会泄漏内存。或者它可能效率低下。或者它可能因某些原因需要13GB。
现在，如果它耗尽内存直到耗尽计算机的资源超出the limits of the OS，那么它很可能是泄漏。
我还建议尝试查找是否有任何操作会触发泄漏。为您的供应商提供重现的步骤有助于。
至于你原来的问题check this SO question。
令我担心的主要问题是它看起来并不像程序实际上正在使用它所要求的所有RAM。我还没有看到私有工作集内存超过4GB。
它必须是32位，在这种情况下，WS永远不会超过4GB。
请在这里查看我的答案。 https://stackoverflow.com/a/44615376/8177258
在任务管理器中：工作集不是内存使用的度量。提交费用是。这就是W8的任务管理器图现在显示Committed而不是WS的原因。
WS是 - RAM - OS平衡管理器为一个或多个进程锁定的数量。它不是负载。
允许32位应用程序在RAM中锁定最大4GB。 64位可以锁定最大8GB。
在x64（Intel64 / AMD64）上，32位应用程序的WS无关紧要，因为任何进程可用的地址空间都是256TB。它仅受CPU和可用存储的限制。
32位应用程序使用的内存很容易超过它的WS，因为32位API已有20年历史，4GB以外的页面被认为是在页面文件上，所以它不会被计算在内。
这些天有一半的机器没有页面文件和8GB-16-32GB的RAM。
然而，CPU报告的系统提交费用仍将攀升。
打开RamMap并查看物理页面中的备用页面，在32位应用程序上查找丢失的工作集数据。
关于RAMMap和VMM。
RAMMapp很棒，因为它显示了物理内存地址（在某种程度上）。你可以从字面上看到页面的位置。
任务管理器中的承诺内存更可靠，因为这是CPU报告的内容。 VMM显示为进程视图之外的任何内容支持的页面文件，因为进程看不到它的虚拟世界。
尽管W7 / W8 / W10改进了它。任务管理器仍然不可靠...... W7中的资源监视器并不算太糟糕。但是有限。
正如有人提到的，因为应用程序没有耗尽所有资源，它可能不是泄漏。当提交的页面没有被解除时，通常会发生泄漏。
我刚刚注意到OP问题有多久了......
@Rick Brant
Windows显示为“已提交”的存储不是RAM。如果需要，它是存储可用性的保证。如果它曾经使用过，存储可能部分在RAM中，部分在页面文件中（假设你有一个页面文件）。
错误。 CPU报告任务管理器中的已提交内存。它知道的唯一页面是写入物理存储器（RAM或HDD）的页面，因为CPU将它们放在那里。
任务管理器中的承诺金额绝对是RAM。
顺便说一句，你前几天给我看过的截图看起来像是在虚拟机上拍摄的。您拥有哪个拥有3个内核的英特尔处理器？
还有关系：第二个测试是泄漏测试，页面没有被解除，这并不意味着它们不在RAM中。 PS ..是什么让你认为DB2是相关的？