1

所以我的问题是关于这个似乎正在吃掉我的服务器内存的exe。它是 Windows Server 2008 R2。重新启动似乎没有帮助，因为提交大小将保持或多或少 13GB。这引起了我的注意，因为由于程序的性能问题，供应商想要更多的 RAM。

让我担心的主要事情是，看起来程序实际上并没有使用它所要求的所有 RAM。我还没有看到私有工作集内存超过 4GB。当用户抱怨运行缓慢并锁定工作站时，我观察了服务器，但它仍然没有使用所有已提交的内存。

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

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

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

感谢您提供任何建议或任何其他故障排除，我可以尝试！

任务管理器 VMMap 结果

4

3 回答 3

2

Windows 中的进程永远不会“提交 RAM”。他们提交虚拟地址空间。

让我担心的主要事情是，看起来程序实际上并没有使用它所要求的所有 RAM。

程序不会“要求 RAM”！他们要求提交的虚拟地址空间。

Windows 显示为“已提交”的存储不是 RAM。如果实际访问它，它是虚拟内存可用性的保证。如果曾经使用过，则存储可能部分位于 RAM 中，部分位于页面文件中（假设您有一个页面文件）。

“工作集（私有）”计数器大致显示了进程的已提交虚拟地址空间中有多少在 RAM 中。我说“大约”是因为部分已提交内存在进程工作集中一段时间​​后可能会移动到修改后的页面列表。从那里它将被快速写入磁盘并移动到备用页面列表，从中可以将 RAM 重新用于其他用途。（或者如果它被带入进程但没有写入，它可以从工作集中直接删除到备用列表。）

这些列表在 RAM 中，但不在工作集中。如果进程引用了仍然在其中一个列表中的页面，则这是一个页面错误，但它是一个软页面错误，无需进入磁盘即可解决。它只是从列表中取出并放回流程工作集中。

虚拟地址空间的“已提交”分配最多只会消耗它们实际访问的 RAM。在任何给定的运行中，程序提交的数量超过它实际使用的数量并不少见……尽管比率通常不是那么大！“最多”是因为操作系统内存管理器可能会从工作集中删除很久以前引用的私有页面，以便为更频繁地访问的内容释放 RAM。

如果该程序导致其他程序因“内存不足”或“内存不足”错误而失败，这将是扩大页面文件的绝佳时机。这些错误消息与提交限制有关，而不是 RAM。扩大您的页面文件将提高提交限制（从而消除错误消息），但由于该程序实际上并没有使用那么多 RAM，因此不会导致更多实际的页面文件 IO！

“提交”机制只是保证一旦操作系统告诉一个进程“因为你已经成功提交了这个数量的虚拟内存，它保证操作系统有一个地方来保存它，即使你碰巧使用了它，稍后在你的奔跑。” 但是，如果程序实际上并未全部引用它，那么它不使用的部分就不会在任何地方占用任何重要的物理存储空间。不在 RAM 中，不在页面文件中，不在任何地方。

于 2017-07-20T01:23:11.610 回答
0

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

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

现在如果它会消耗内存，直到耗尽计算机的资源超出操作系统的限制，那么很可能存在泄漏。

我还建议尝试查找是否有任何操作会触发泄漏。为您的供应商提供重现步骤会有所帮助。

至于你原来的问题， 请检查这个 SO question。

参考

于 2014-05-02T18:37:19.760 回答
0

让我担心的主要事情是，看起来程序实际上并没有使用它所要求的所有 RAM。我还没有看到私有工作集内存超过 4GB。

它必须是 32 位，在这种情况下 WS 永远不会爬升超过 4GB。

请在此处查看我的答案。 https://stackoverflow.com/a/44615376/8177258

在任务管理器中：工作集不是内存使用的衡量标准。提交费用是。这就是 W8 中的任务管理器图表现在显示已提交而不是 WS 的原因。

WS 是操作系统平衡管理器为一个或多个进程锁定的 RAM 量。它不是负载。

允许 32 位应用程序在 RAM 中锁定最大 4GB。64位最大可以LOCK 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问题有多老了......

@里克布兰特

Windows 显示为“已提交”的存储不是 RAM。如果需要，它是存储可用性的保证。如果曾经使用过，则存储可能部分位于 RAM 中，部分位于页面文件中（假设您有一个页面文件）。

错误的。任务管理器中的已提交内存由 CPU 报告。它知道的唯一页面是写入物理存储的页面，无论是 RAM 还是 HDD，因为 CPU 将它们放在那里。

任务管理器中的承诺量绝对是 RAM。

顺便说一句，你前几天给我看的那个截图看起来像是在虚拟机上拍摄的。你有哪个 Intel 处理器有 3 个内核？

也相关：第二次测试是泄漏测试，页面没有被解除，这并不意味着它们不在 RAM 中。PS..是什么让您认为 DB2 是相关的？

于 2017-08-04T04:00:50.370 回答