当 SQL Server 没有可用的物理内存时会发生什么?

Rau*_*DBA 16 sql-server data-pages memory tempdb sql-server-2014

在谷歌搜索时,我发现了一些相互矛盾的信息。

某些站点指出,当没有为数据留下物理内存时,SQL Server 会将现有数据移动到 TEMPDB(请参阅:SQL Server:揭秘 TempDb 和建议)。

但是其他站点声明,当没有足够的物理内存时,操作系统可以使用 PAGE FILE 并将数据从物理内存移到它(请参阅SQL Server 的页面文件)。

我想知道当 SQL Server 物理内存不足时,它会在哪里写入数据?到 tempdb 还是到 OS Page 文件?或者两者都有?

Jos*_*ell 28

当没有用于数据的物理内存时,SQL Server 将已经存在的数据移动到 TEMPDB

您链接到的文章充其量具有误导性,并且在某些地方是不正确的。我认为作者试图过度简化一些复杂的事情,这样做有点过分了。

SQL Server 不会以这种方式将数据从内存(缓冲池)移动到 tempdb。它使用“最近最少使用”的缓存策略(一般情况下),因此如果存在内存压力,并且需要将新数据拉入内存,SQL Server 将从缓冲池中踢出 LRU 数据以容纳新数据。这种行为通常由一个名为“页面预期寿命”(PLE)的性能计数器监控:

PLE 的定义是读入缓冲池(数据文件页面的内存缓存)的数据文件页面在被推出内存之前将保留在内存中以便为不同的数据腾出空间的预期时间(以秒为单位)文件页面。另一种考虑 PLE 的方式是对缓冲池压力的即时测量,以便为从磁盘读取的页面腾出可用空间。对于这两个定义,数字越大越好。

在查询执行期间,SQL Server可以使用 tempdb 进行某些操作。如果估计值不好,通常会这样做,但可用内存不足会影响这种行为。

可以通过这种方式“溢出”到 tempdb 的一些操作是散列行(用于连接或聚合等)、对内存中的行进行排序以及在并行查询执行期间缓冲行。

用户查询还可以显式使用 tempdb(使用全局或本地临时表),并隐式使用 tempdb(使用快照或读取提交的快照隔离级别)。

这些情况似乎都不符合您引用的陈述。

当没有足够的物理内存时,操作系统可以使用 PAGE FILE 并将数据从物理内存移动到它

这肯定会发生,并且在大多数情况下不在 SQL Server 的控制范围内。您可以转动一个旋钮来尝试防止某些类型的操作系统级分页,即打开“Lock Pages in Memory”(LPIM)

此 Windows 策略确定哪些帐户可以使用进程将数据保存在物理内存中,从而防止系统将数据分页到磁盘上的虚拟内存。

那么我们可以防止被分页到磁盘吗?

在 SQL Server 2012 之前,通过称为“单页分配器”的组件分配的页面被锁定在内存中(无法分页)。这包括缓冲池(数据库页面)、过程缓存和一些其他内存区域。

有关详细信息,请参阅“锁定页面的乐趣”、AWE、任务管理器和工作集……了解详情,尤其是“4. 现在我知道 x64 上的 SQL Server 可以使用“锁定页面”,究竟锁定了什么?” 其他相关阅读可以在这里找到:Great SQL Server Debates: Lock Pages in Memory

在 SQL Server 2012 及更高版本中,没有“单页分配器”(根据深入了解内存 – SQL Server 2012/2014,单页和多页分配器已合并)。我所见过的任何地方都没有详细记录可以分页和不能分页的详细信息。您可以使用查询这样的,看看有什么锁定:

select osn.node_id, osn.memory_node_id, osn.node_state_desc, omn.locked_page_allocations_kb
from sys.dm_os_memory_nodes omn
inner join sys.dm_os_nodes osn on (omn.memory_node_id = osn.memory_node_id)
where osn.node_state_desc <> 'ONLINE DAC'
Run Code Online (Sandbox Code Playgroud)

根据同一篇 MS 支持文章,您还DBCC MEMORYSTATUS可以查看“锁定”了多少内存。

作为旁注,您可以在错误日志中看到操作系统对 SQL Server 的工作集进行分页的证据。会有类似这样的消息:

2019-09-02 10:19:27.29 spid11s sql server 进程内存的很大一部分已被调出。这可能会导致性能下降。持续时间:329 秒。工作集 (KB):68780,已提交 (KB):244052,内存利用率:28%。