windows Process Explorer：提交历史图显示什么？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/6598097/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Process Explorer: What does the Commit History graph show?
提问by Ashwin Nanjappa
In the Memorygraph available in Process Explorer, the top graph shows Commit History. What does this actually indicate at the OS level?
在Process Explorer 中可用的Memory图表中，顶部图表显示Commit History。这在操作系统级别实际上表明了什么？
To experiment if this is the memory allocated on the heap by a process, I wrote a small program that incrementally malloc-ed 100 MB many times. The Commit History graph increased for a while (upto 1.7 GB of memory allocation) and did not grow after that despite the program malloc-ing memory.
为了试验这是否是进程在堆上分配的内存，我编写了一个小程序，多次将 100 MB 增量地分配给内存。Commit History 图增加了一段时间（最多 1.7 GB 的内存分配），之后尽管程序 malloc-ing 内存但没有增长。
So, what is this graph indicating? How can this information be used to understand/analyse the state of Windows?
那么，这张图说明了什么？如何使用此信息来了解/分析 Windows 的状态？
回答by P.T.
The Commit level is the amount of anonymous virtual address space allocated to all processes in the system. (It does not include any file-backed virtual address space, e.g., from an mmap'd file.) In process explorer, the 'Commit History' graph shows the size of this value over time.
提交级别是分配给系统中所有进程的匿名虚拟地址空间量。（它不包括任何文件支持的虚拟地址空间，例如，来自一个 mmap 的文件。）在进程资源管理器中，“提交历史”图显示该值随时间变化的大小。
Because of the way virtual memory is allocated and parceled out (the actual RAM backing a page of virtual address space isn't necessarily allocated until its first touched), this current 'commit' level represents the worst case (at the moment) of memory that the system may have to come up with. Unlike Linux, Windows will not hand out promises (address space) for RAM it cannot come up with or fake (via the paging file). So, once the commit level reaches the limit for the system (roughly RAM + pageing file size), new address space allocations will fail (but new uses of existing virtual address space regions will not fail).
由于虚拟内存的分配和分配方式（支持虚拟地址空间页面的实际 RAM 在第一次接触之前不一定分配），当前的“提交”级别代表内存的最坏情况（目前）系统可能不得不提出。与 Linux 不同，Windows 不会为它无法提供或伪造的 RAM（通过分页文件）分发承诺（地址空间）。因此，一旦提交级别达到系统的限制（大约 RAM + 分页文件大小），新的地址空间分配将失败（但现有虚拟地址空间区域的新使用不会失败）。
Some conclusions about your system that you can draw from this value:
您可以从该值中得出有关您的系统的一些结论：
- If this value is less than your current RAM (excepting the kernel and system overhead), then your system is very unlikely to swap (use the paging file) since in the worst case, everything should fit in memory.
- If this value is much larger than physical memory usage, then some program is allocating a lot of virtual address space, but isn't yet using it.
- Exiting an application should reduce the committed memory usage as all of its virtual address space will be cleaned up.
- 如果此值小于您当前的 RAM（内核和系统开销除外），则您的系统不太可能交换（使用页面文件），因为在最坏的情况下，所有内容都应该适合内存。
- 如果此值远大于物理内存使用量，则某些程序正在分配大量虚拟地址空间，但尚未使用它。
- 退出应用程序应减少已提交的内存使用量，因为其所有虚拟地址空间都将被清理。
Your experiment validated this. I suspect you ran into address space limitations (32-bit processes in windows are limited to 2GB... maybe 300MB disappeared to fragmentation, libraries and text?).
你的实验证实了这一点。我怀疑您遇到了地址空间限制（Windows 中的 32 位进程被限制为 2GB...也许 300MB 消失在碎片、库和文本中？）。
