【问题标题】:Commit size much higher than the Working Set提交大小远高于工作集
【发布时间】:2020-07-28 18:16:57
【问题描述】:

在我们的一台托管 SQL Server 数据库实例的 Windows 服务器中,我可以看到一个 SQLServer.exe 进程的提交大小和工作集存在巨大差异(来自资源监视器)

  • 提交(KB):162 186 000
  • 工作集 (KB):1 296 800

我了解提交大小包括使用的 RAM + 虚拟内存。我检查了服务器中pagefile.sys 的大小,发现它只有8GB 大。那么剩下的虚拟内存在哪里呢?在 RAM 本身上?

请澄清

【问题讨论】:

    标签: sql-server memory windows-server-2012


    【解决方案1】:

    这是一个相当复杂的话题,如果您想要真正详细的答案,您可以阅读大量有关操作系统如何处理“内存”的深入而翔实的文章,例如 this old one

    但是,如果您想要一份执行摘要:“提交费用”可能根本没有分配到 RAM 或磁盘上!它代表“虚拟地址空间”的提交,是一种“映射”。

    当一个进程“增加”其提交费用时,实际情况如下:它对操作系统说“你好,我想使用 X 内存量”,而操作系统说“好的,我保证你可以访问 X内存量”。它通过在虚拟地址空间“映射”中“分配”地址空间来做到这一点。但是那只是一张地图。这并不意味着已经实际上分配了任何内存 - 无论是从 RAM 还是从磁盘!

    打个比方,假设您正在预订酒店房间。你打电话给酒店说“你好,我想在这个周六和周日订一个房间”。接待员查看预订日历,发现 28 号房间是免费的。他们告诉你“好的,我已经为你预订了这个周六和周日”。在这里,接待员的日历就是“虚拟房间空间”的“地图”。接待员通过更新地图向您保证了这个房间。但是您实际上还没有使用这个房间。你不在里面,你的包和衣服都不在里面。您刚刚完成了预订。

    提交费用包括您的应用程序所做的所有“预订”,而操作系统是接待员。您的应用程序可能尚未使用预订的空间,但操作系统已保证您可以根据需要使用该空间。

    【讨论】:

    • 感谢 allmhuran 的总结。它确实分享了一些关于操作系统如何处理虚拟地址空间的见解。但就我而言,似乎大部分虚拟地址空间都保留在 RAM 中,而保留空间实际上被计为已用内存。早些时候,SQL Server 实例的最大服务器内存设置为约 160GB,后来我们将其降低到 80GB,随之服务器总内存利用率从 93% 下降到 74%。
    • @aok 是的,提交的内存可以由 ram 或磁盘保证,一旦保证它可以被进程使用。还有某些类型的内存分配以不同的方式显示。这些分配可能不会显示在“工作集”中,尽管它们是提交费用的一部分在 RAM 中。 SQL Server 使用的大部分内存将是缓冲池。如果一个 Sql server 开始分页,它可能是一个 Sql server 会死掉,所以它需要“真正的 RAM”。
    • 我认为大小是 VAD 中分配的大小,提交可能是页表条目不为空的数量(包括有效的(硬件)PTE、页面文件PTE,过渡 PTE),还可能包括 VAD PTE 和指向原型 PTE 的 PTE
    猜你喜欢
    • 2013-01-16
    • 2014-08-18
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-10-16
    • 2014-04-06
    • 2012-04-01
    相关资源
    最近更新 更多