什么是私有字节，虚拟字节，工作集？ [英] What is private bytes, virtual bytes, working set?

问题描述

Perfon说明：

我正在使用perfmon windows实用程序来调试内存泄漏。 > 工作集 - 工作集是此进程的工作集的当前大小（以字节为单位）。工作集是进程中线程最近触摸的一组内存页。如果计算机中的可用内存高于阈值，则即使不使用页面仍在进程的工作集中。当空闲内存低于阈值时，页面将从工作集中修剪。如果需要，那么在离开主内存之前，它们会被软错误地返回到工作集中。

虚拟字节 - 虚拟字节是虚拟地址空间的当前大小（以字节为单位）。使用虚拟地址空间并不一定意味着相应地使用磁盘或主内存页面。虚拟空间是有限的，进程可以限制其加载库的能力。

专用字节 - 专用字节是当前大小，以字节为单位，这个进程分配的内存不能与其他进程共享。

Q1。是否应该测量私有字节，以确保该进程是否有任何泄漏，因为它不涉及任何共享库，如果发生这种情况，则会发生泄漏？

Q2。进程消耗的总内存是多少？是虚拟字节还是虚拟字节和工作集的总和

Q3。私有字节，工作集和虚拟字节之间有任何关系。

Q4。任何提供更好的记忆信息的工具？

解决方案

这个问题的简短答案是这些值都不是可执行文件实际使用多少内存的可靠指标，并且它们都不适合调试内存泄漏。

私人字节是指流程可执行文件要求的内存量 - 不一定是实际使用的数量。它们是私有的，因为它们（通常）排除内存映射文件（即共享的DLL）。但是 - 这是catch - 它们不一定排除这些文件分配的内存。无法确定私有字节的更改是由于可执行文件本身还是由于链接库而导致的。专用字节也是不专用物理内存;它们可以被分页到磁盘或备用页面列表中（即不再使用，但没有分页）。

工作集指的是进程使用的总体物理内存（RAM）。然而，与私有字节不同，这也包括内存映射文件和各种其他资源，因此它比私有字节更精确。这是在任务管理器的使用记忆中报告的相同值，并且是近年来无限量混乱的根源。在工作集中的内存是物理的，它可以在没有页面错误的情况下被解决;但是，待机页面列表还是物理上位于内存中，但未在工作集中报告，这就是为什么在最小化应用程序时可能会看到内存使用量突然下降的原因。

虚拟字节是整个进程占用的总计虚拟地址空间。这就像工作集一样，它包括内存映射文件（共享DLL），但它还包括备用列表中的数据和已经被分页出来的数据，并且位于磁盘上的某个页面文件中。在重负载下，系统上的每个进程使用的总虚拟字节将增加显着多于机器实际拥有的内存。

所以关系是：

• 私人字节是您的应用实际分配的，但包含页面文件使用情况;


• 工作集是非分页专用字节加内存映射文件;


• 虚拟字节是工作集加分页专用字节和备用列表。

这里还有一个问题;正如共享库可以在应用程序模块中分配内存，导致应用程序私有字节中报告的潜在错误，您的应用程序也可能会最终在共享模块中分配内存，导致假阴性。这意味着您的应用程序实际上可能存在内存泄漏，从而不会在私有字节中显示内存泄漏。

私人字节是可执行文件使用的内存量的合理近似，可用于帮助缩小内存泄漏潜在候选人列表如果您看到数字不断增长并持续增长，您将需要检查该过程是否有泄漏。但是，这不能证明有或没有泄漏。

检测/纠正内存泄漏的最有效工具之一Windows实际上是 Visual Studio （链接到页面使用VS内存泄漏，而不是产品页面）。 Rational Purify 是另一种可能性。 Microsoft还有一个更一般的最佳做法文档这个主题。此上一个问题中列出了更多工具。 p>

我希望这可以清除一些事情！跟踪内存泄漏是调试中最难做的事情之一。祝你好运。

I am using the perfmon windows utility to debug memory leaks in a process.

Perfmon explanation:

Working Set- Working Set is the current size, in bytes, of the Working Set of this process. The Working Set is the set of memory pages touched recently by the threads in the process. If free memory in the computer is above a threshold, pages are left in the Working Set of a process even if they are not in use. When free memory falls below a threshold, pages are trimmed from Working Sets. If they are needed they will then be soft-faulted back into the Working Set before leaving main memory.

Virtual Bytes- Virtual Bytes is the current size, in bytes, of the virtual address space the process is using. Use of virtual address space does not necessarily imply corresponding use of either disk or main memory pages. Virtual space is finite, and the process can limit its ability to load libraries.

Private Bytes- Private Bytes is the current size, in bytes, of memory that this process has allocated that cannot be shared with other processes.

Q1. Is it the Private Bytes which I should measure to be sure if the process is having any leaks as it does not involve any shared libraries and any leaks if happening will come from the process itself?

Q2. What is the total memory consumed by the process? Is it the Virtual Bytes or is it the sum of Virtual Bytes and Working Set

Q3. Is there any relation between Private Bytes, Working Set and Virtual Bytes.

Q4. Any tool which gives a better idea memory information?

解决方案

The short answer to this question is that none of these values are a reliable indicator of how much memory an executable is actually using, and none of them are really appropriate for debugging a memory leak.

Private Bytes refer to the amount of memory that the process executable has asked for - not necessarily the amount it is actually using. They are "private" because they (usually) exclude memory-mapped files (i.e. shared DLLs). But - here's the catch - they don't necessarily exclude memory allocated by those files. There is no way to tell whether a change in private bytes was due to the executable itself, or due to a linked library. Private bytes are also not exclusively physical memory; they can be paged to disk or in the standby page list (i.e. no longer in use, but not paged yet either).

Working Set refers to the total physical memory (RAM) used by the process. However, unlike private bytes, this also includes memory-mapped files and various other resources, so it's an even less accurate measurement than the private bytes. This is the same value that gets reported in Task Manager's "Mem Usage" and has been the source of endless amounts of confusion in recent years. Memory in the Working Set is "physical" in the sense that it can be addressed without a page fault; however, the standby page list is also still physically in memory but not reported in the Working Set, and this is why you might see the "Mem Usage" suddenly drop when you minimize an application.

Virtual Bytes are the total virtual address space occupied by the entire process. This is like the working set, in the sense that it includes memory-mapped files (shared DLLs), but it also includes data in the standby list and data that has already been paged out and is sitting in a pagefile on disk somewhere. The total virtual bytes used by every process on a system under heavy load will add up to significantly more memory than the machine actually has.

So the relationships are:

• Private Bytes are what your app has actually allocated, but include pagefile usage;
• Working Set is the non-paged Private Bytes plus memory-mapped files;
• Virtual Bytes are the Working Set plus paged Private Bytes and standby list.

There's another problem here; just as shared libraries can allocate memory inside your application module, leading to potential false positives reported in your app's Private Bytes, your application may also end up allocating memory inside the shared modules, leading to false negatives. That means it's actually possible for your application to have a memory leak that never manifests itself in the Private Bytes at all. Unlikely, but possible.

Private Bytes are a reasonable approximation of the amount of memory your executable is using and can be used to help narrow down a list of potential candidates for a memory leak; if you see the number growing and growing constantly and endlessly, you would want to check that process for a leak. This cannot, however, prove that there is or is not a leak.

One of the most effective tools for detecting/correcting memory leaks in Windows is actually Visual Studio (link goes to page on using VS for memory leaks, not the product page). Rational Purify is another possibility. Microsoft also has a more general best practices document on this subject. There are more tools listed in this previous question.

I hope this clears a few things up! Tracking down memory leaks is one of the most difficult things to do in debugging. Good luck.

这篇关于什么是私有字节，虚拟字节，工作集？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！