Windows 2008R2上SQL 2008R2的建议页面文件大小

此Microsoft文章- 如何确定64位版本的Windows Server 2008和/或Windows 2008 R2的适当页面文件大小，提供了计算64位Windows 2008和Windows 2008R2的页面文件大小的指南。毫无疑问，这对于通用服务器来说效果很好。我想知道针对在Windows 2008 / R2 64位上运行的SQL Server 2008R2的指导是什么？

我假设我们希望内存中的数据少到页面文件，否则SQL可能两次在磁盘上打数据。SQL Server甚至允许内存中的数据访问页面文件吗？我已经通过SQL Server 2008 R2联机丛书寻求指导，但是还没有提到页面文件的使用。

这是一个潜在的使用场景：给具有64GB RAM的物理服务器，整个64GB RAM是否需要页面文件？我们是否应该为96GB的页面文件做好准备？对于单个文件，这似乎有点过分。我知道传统的看法是Windows会将页面文件耦合到内存，以尝试在RAM上更容易地换出应用程序，但这是真的吗？小于64GB的页面文件会在此处影响性能吗？

— 凯夫
source

Answers:

没有专门用于通常仅使用物理内存的SQL Server的特殊设置

只需执行MS对于Windows所说的即可

哦，无论如何，当我们成为主题之一时，再购买更多RAM ... ;-)

— gbn
source

看看lock pages in memory。这样，您可以让您的SQL服务帐户优先使用可用的RAM，而不是分页到磁盘。要了解有关内存中锁定页的更多信息，请单击此链接。以下是一个摘要：

默认情况下，Windows策略“锁定内存中的页面”选项处于禁用状态。必须启用此特权才能配置地址窗口扩展（AWE）。此策略确定哪些帐户可以使用进程将数据保留在物理内存中，从而防止系统将数据分页到磁盘上的虚拟内存。在32位操作系统上，不使用AWE时设置此特权可能会严重损害系统性能。在64位操作系统上，不需要锁定内存中的页面。

在系统上使用之前，请测试此功能。

— 斯坦利·约翰斯
source

最好将“锁定内存中的页面”描述为一种安全措施，以防止SQL内存被操作系统调出。support.microsoft.com/kb/918483

— 马克·斯托里·史密斯

是的，对于64GB RAM，您至少需要64GB交换文件（建议96GB）。不是因为潜在的交换，而是因为Windows内存管理器的设计。我之前在具有大RAM的计算机上的System pagefile size中写过有关此问题的文章：

当进程MEM_COMMIT通过VirtualAlloc/ 要求内存时 VirtualAllocEx，需要在页面文件中保留请求的大小。在第一个Win NT系统中就是如此，今天仍然如此，请参见在Win32中管理虚拟内存：

提交内存后，将分配内存的物理页面，并在页面文件中保留空间。

另一种可能是类似oom_killer的东西。

因此，请务必遵循建议，有时情况会比看起来复杂一些。而且我什至都没有触及AWE和锁定页面特权带来的麻烦...

— 雷木斯·鲁萨努（Remus Rusanu）
source

非常有趣...当您设置一个小于计算机RAM的交换文件时，它如何工作？如果确实需要为每次内存分配保留页面文件中的空间，那么我们将无法使用超出页面文件大小的内存容量的更多内容？我不确定这是如何运作的。

— shlomoid 2011年

这就是实际上的工作方式。提交的VA区域必须由实际的交换保留来支持。一个保留 VA区域不必须，但SQL Server几乎从未请求未提交的预订。

— Remus Rusanu

我认为这是不正确的。我从Windows Internals书籍等各种来源了解到，提交的虚拟地址空间必须由物理文件（页面文件或RAM）支持。因此，如果您尝试提交虚拟内存>（[Windows看到的物理内存+ +分页文件大小]），则会收到臭名昭著的“您的系统虚拟内存不足”错误消息。马克·鲁西诺维奇（Mark Russinovich）在此处的 “承诺的内存”一节中谈到了这一点。

— James L

我认为您可以通过启动没有分页文件的系统并确认Windows启动来确认自己已确认的VA区域不必由交换保留来支持，因此必须有超过0字节的已提交的VAS。

— 詹姆斯L

这篇文章是错误的-如果您的内存超过最大提交要求，则完全可以在没有页面文件的情况下运行。但是，这将意味着您无法编写故障转储。

— Steve365 '16