什么是私有字节、虚拟字节、工作集? [英] What is private bytes, virtual bytes, working set?
问题描述
我正在尝试使用 perfmon windows 实用程序来调试进程中的内存泄漏.
这是 perfmon 对这些术语的解释:
Working Set 是此进程的工作集的当前大小(以字节为单位).工作集是进程中线程最近触及的内存页集.如果计算机中的可用内存高于阈值，即使页面未在使用，页面也会留在进程的工作集中.当可用内存低于阈值时，将从工作集中修剪页面.如果需要它们，它们将在离开主内存之前软故障返回到工作集.
Virtual Bytes 是进程正在使用的虚拟地址空间的当前大小(以字节为单位).使用虚拟地址空间并不一定意味着相应地使用磁盘或主内存页面.虚拟空间是有限的，进程可以限制其加载库的能力.
Private Bytes 是此进程分配的不能与其他进程共享的当前内存大小(以字节为单位).
这些是我的问题:
是我应该测量的私有字节数以确保进程是否有任何泄漏，因为它不涉及任何共享库，并且任何泄漏(如果发生)将来自进程本身?
进程消耗的总内存是多少?是虚拟字节数还是虚拟字节数和工作集的总和?
私有字节、工作集和虚拟字节之间有什么关系吗?
是否有其他工具可以更好地了解内存使用情况?
这个问题的简短回答是这些值都不是可执行文件实际使用多少内存的可靠指标，也没有一个非常适合调试内存泄漏.
私有字节是指进程可执行文件要求的内存量 - 不一定是它实际使用的量.它们是私有的"，因为它们(通常)排除内存映射文件(即共享 DLL).但是——这里有一个问题——它们不一定排除由这些文件分配的内存.无法判断私有字节的更改是由于可执行文件本身还是由于链接库引起的.私有字节也不专属于物理内存；它们可以分页到磁盘或备用页面列表中(即不再使用，但也未分页).
工作集是指进程使用的总物理内存 (RAM).但是，与私有字节不同，这还包括内存映射文件和各种其他资源，因此它的测量精度甚至低于私有字节.这与任务管理器的内存使用情况"中报告的值相同，并且近年来一直是无数混乱的根源.工作集中的内存是物理的"，因为它可以在没有页面错误的情况下被寻址；然而，备用页面列表也仍然在物理内存中，但没有在工作集中报告，这就是为什么当你最小化应用程序时，你可能会看到内存使用"突然下降.
Virtual Bytes 是整个进程占用的总虚拟地址空间.这就像工作集，从某种意义上说，它包括内存映射文件(共享 DLL)，但它也包括备用列表中的数据和已经被调出并位于磁盘上某个页面文件中的数据.在重负载下，系统上每个进程使用的总虚拟字节数加起来会比机器实际拥有的内存多得多.
所以关系是:
- Private Bytes 是您的应用实际分配的内容，但包括页面文件使用情况；
- 工作集是非分页私有字节加上内存映射文件；
- 虚拟字节是工作集加上分页私有字节和备用列表.
这里还有一个问题；正如共享库可以在您的应用程序模块内分配内存，导致在您的应用程序的 Private Bytes 中报告潜在的误报一样，您的应用程序也可能最终在 shared 模块内分配内存，导致假否定.这意味着您的应用程序实际上可能存在内存泄漏，而这种泄漏根本不会在私有字节中表现出来.不太可能，但可能.
私有字节是您的可执行文件使用的内存量的合理近似值，可用于帮助缩小内存泄漏的潜在候选列表；如果您看到数字不断增长且无休止地增长，您可能需要检查该过程是否存在泄漏.但是，这不能证明是否存在泄漏.
在 Windows 中检测/纠正内存泄漏的最有效工具之一实际上是 Visual Studio(链接转到使用 VS 解决内存泄漏的页面，而不是产品页面).Rational Purify 是另一种可能性.微软还有一个更通用的最佳实践文档，关于这个主题.此上一个问题中列出了更多工具.>
我希望这可以解决一些问题！跟踪内存泄漏是调试中最困难的事情之一.祝你好运.
I am trying to use the perfmon windows utility to debug memory leaks in a process.
This is how perfmon explains the terms:
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 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 is the current size, in bytes, of memory that this process has allocated that cannot be shared with other processes.
These are the questions I have:
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?
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?
Is there any relation between Private Bytes, Working Set and Virtual Bytes?
Are there any other tools that give a better idea of the memory usage?
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屋！
