windows – 进程的Private Bytes如何显着低于对系统提交费用的影

发布时间：2020-12-14 00:33:16 所属栏目：Windows 来源：网络整理

导读：在64位 Windows Server 2003上,我可以看到使用taskmgr或进程资源管理器,总提交费用大约为3.5GB,但是当我对每个进程消耗的专用字节数进行求和时(通过运行pslist -m并添加所有值) Priv栏)总数为1.6GB. 我知道哪个进程似乎导致了这个(sqlservr.exe),因为当我杀

在64位 Windows Server 2003上,我可以看到使用taskmgr或进程资源管理器,总提交费用大约为3.5GB,但是当我对每个进程消耗的专用字节数进行求和时(通过运行pslist -m并添加所有值) Priv栏)总数为1.6GB.

我知道哪个进程似乎导致了这个(sqlservr.exe),因为当我杀死进程时,提交费用急剧下降.然而,有问题的过程只消耗~220MB的私有字节,但是杀死进程会使提交费减少~1.6GB.

这怎么可能？如果提交费用如此显着大于私有字节,它应该代表已提交内存的数量？如果某些其他因素导致提交费用,那么该因素是什么？如何在流程资源管理器中查看其影响？

注意：我声称我已经理解了保留和已提交内存之间的区别：我上面的调查专门涉及私有字节,其中仅包含已提交的内存并且不包括保留的内存.在这种情况下,进程的虚拟大小超过4GB,但这应该是无关紧要的 – procexp中的虚拟大小表示保留,而不是已提交的内存,并且不应对提交费用做出贡献.

我对这个问题的一般答案特别感兴趣：我假设如果sqlservr.exe可以以这种方式运行,那么任何进程都可能.

进一步调查

我注意到在这个过程中指向Sysinternals VMMap报告了一个1.6GB的承诺“私有数据”,尽管Procexp报告的私有字节数为220MB.鉴于“Windows?Sysinternals管理员参考”中此字段的文档指出：

Private Data memory is memory that is allocated by VirtualAlloc and that is not further handled by the Heap Manager or the .NET runtime,or assigned to the Stack category… VMMap’s definition of “Private Data” is more granular than that of
Process Explorer’s “private bytes.” Procexp’s “private bytes” includes
all private committed memory belonging to the process.

即VMMap提交的“私有数据”应小于procexp的“私有字节”.

此外,在阅读了Mark Russinovich出色的Pushing the Limits of Windows: Virtual Memory的“过程承诺记忆”部分后,他强调了两个不会出现在私人字节中的案例：

>具有写时复制语义的文件映射视图(但是,根据VMMap,没有为映射文件分配大量空间).
>页面文件支持的虚拟内存(但是,我按照建议尝试了带有-l标志的testlimit,并且页面文件支持的部分没有消耗大量内存)

编辑：请注意,评论部分现在无关紧要,因为我原来的答案消失了.

你的问题：

How can the Private Bytes of a process be significantly less than its effect on the system commit charge?

这可以通过Mark Russinovich的直接引用来回答：

There are two types of process virtual memory that do count toward the commit limit: private and pagefile-backed.

归因于该进程的私有字节可以(并且通常)小于该进程对系统提交费用的影响,因为该进程还可以分配由页面文件支持的虚拟内存.

页面文件支持的虚拟内存很难归因于特定进程,因为它可以在进程之间共享.没有特定于进程的性能计数器可以告诉您任何进程已分配或引用了多少页面文件支持的虚拟内存,但它仍然会计入提交限制.

This article是关于该主题的权威文章,在该文章中,他专门演示了一个进程分配了大量页面文件支持的VM的情况,但该进程的私有字节仍然很低.

他还向您展示了如何使用handle.exe来检测节对象的句柄的分配大小.这就是你如何检测哪些进程对提交费用产生如此大的影响.

您提到您已经使用handle.exe查看了sqlservr.exe,并且它没有处理大量部分对象的句柄,这些句柄会占用您杀死sqlservr.exe时释放的提交费用.

巧合的是,内核空间中还有内存分配,这些分配是针对系统提交限制收取的,例如分页和非分页池,以及驱动程序锁定内存,包括虚拟机气球驱动程序等等.我不认为这与这个案子,但我不想让它没有说明.

SQL Server是一个庞大而复杂的产品,由许多不同的进程组成,这些进程在系统上协同工作以提供所有SQL Server服务.事实上,SQL Server有自己的内部内存管理器,从用于测量Windows虚拟内存分配的工具的角度来看,它可以使它看起来非常典型.

sqlservr.exe不单独执行.还有

> msmdsrv.exe(Analysis Services)
> sqlwriter.exe(SQL VSS编写器)
> sqlagent.exe(SQL代理)
> fdlauncher.exe(全文本过滤器守护程序启动器)
> fdhost.exe(全文主机)
> ReportingServicesService.exe
> SQLBrowser.exe

当我杀死sqlservr.exe时,sqlagent.exe也会自动死掉.这意味着系统提交费用将减少两个流程为其提供的金额.当sqlservr.exe被杀死时,其他与SQL相关的进程也可能正在释放由页面文件支持的部分,即使进程本身仍在运行.当sqlservr.exe被杀死时,所有这些都会导致系统的当前提交费用下降,即使它们从不是sqlservr.exe的私有字节的一部分.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!