在Process Explorer中可用的Memory图表中,顶部图表显示Commit History。这在操作系统级别实际上表明了什么?
为了试验这是否是进程在堆上分配的内存,我编写了一个小程序,多次递增地 malloc-ed 100 MB。Commit History 图表增加了一段时间(最多 1.7 GB 的内存分配),此后尽管程序 malloc-ing 内存并没有增长。
那么,这张图说明了什么?如何使用这些信息来理解/分析 Windows 的状态?
在Process Explorer中可用的Memory图表中,顶部图表显示Commit History。这在操作系统级别实际上表明了什么?
为了试验这是否是进程在堆上分配的内存,我编写了一个小程序,多次递增地 malloc-ed 100 MB。Commit History 图表增加了一段时间(最多 1.7 GB 的内存分配),此后尽管程序 malloc-ing 内存并没有增长。
那么,这张图说明了什么?如何使用这些信息来理解/分析 Windows 的状态?
提交级别是分配给系统中所有进程的匿名虚拟地址空间量。(它不包括任何文件支持的虚拟地址空间,例如,来自 mmap 文件。)在进程资源管理器中,“提交历史”图表显示了该值随时间变化的大小。
由于分配和分配虚拟内存的方式(支持虚拟地址空间页面的实际 RAM 在第一次接触之前不一定分配),当前的“提交”级别代表了内存的最坏情况(目前)系统可能必须提出。与 Linux 不同,Windows 不会为它无法提供或伪造的 RAM(通过页面文件)提供承诺(地址空间)。因此,一旦提交级别达到系统的限制(大致为 RAM + 分页文件大小),新的地址空间分配将失败(但对现有虚拟地址空间区域的新使用不会失败)。
你可以从这个值中得出一些关于你的系统的结论:
你的实验证实了这一点。我怀疑您遇到了地址空间限制(Windows 中的 32 位进程限制为 2GB ......也许 300MB 消失在碎片、库和文本中?)。