Sql server 适合SQL Server的Windows O/S页面文件大小

对于运行SQL server的Windows 2003 server，有没有人知道合适的页面文件大小的经验法则？

如果您希望获得高性能，您将希望完全避免页面，因此页面文件大小变得不那么重要。为DB服务器投资尽可能多的RAM。

越大越好，达到应用程序工作集的大小，您将开始进入收益递减状态。您可以尝试通过缓慢增加或减少大小来找到这一点，直到您看到缓存命中率的显著变化。但是，如果缓存命中率超过90%左右，您可能就可以了。通常情况下，您应该在生产系统上注意这一点，以确保其内存分配没有超出限制。

最近，我们的一台SQL Server出现了一些性能问题，我们无法完全解决这些问题，实际上，我们使用了一个Microsoft支持票证来帮助解决这些问题。SQL Server使用的最佳页面文件大小出现了，Microsoft建议它是RAM大小的1 1/2倍，与RAM大小无关，您仍然需要至少是物理RAM大小1.5倍的页面文件。这是真的，即使你有一台1 TB的RAM机器，你也需要1.5 TB的页面文件在磁盘上（听起来很疯狂，但这是真的）

当进程通过VirtualAlloc/VirtualAllocEx请求MEM_提交内存时，需要在页面文件中保留请求的大小。这在第一个Win NT系统中是正确的，今天仍然是正确的，请参见：

当提交内存时，物理 内存页被分配到和 页面文件中保留了空间

在某些极端的情况下，SQL Server总是要求提交MEM_页面。考虑到SQL使用的策略是预先保留尽可能多的缓冲池（根据VAS保留和提交），SQL Server将在启动时请求在页面文件中保留大量空间。如果页面文件大小不正确，错误801/802将开始显示在SQL的错误日志文件和操作中

这总是会引起一些混乱，因为管理员错误地认为大RAM消除了对页面文件的需要。事实恰恰相反，一个大的RAM增加了对页面文件的需求，这仅仅是因为WindowsNT内存管理器的内部工作。希望保留的页面文件从未被使用过

根据微软的说法，“随着计算机内存量的增加，对页面文件的需求就会减少。”文章接着描述了如何使用性能日志来确定页面文件实际使用了多少。首先尝试将页面文件设置为1.5X系统内存，然后执行建议的监视并从中进行调整

---

经过大量研究，在Windows 2003 Enterprise x64上运行Enterprise x64的专用SQL服务器没有页面文件

简单地说，页面文件是由操作系统管理的文件的缓存，SQL有自己的内部内存管理系统

引用的MS文章没有限定该建议适用于运行开箱即用服务（如文件共享）的操作系统

---

拥有一个页面文件只会加重磁盘I/O的负担，因为Windows正试图提供帮助，而只有SQL操作系统才能完成这项工作。

我非常尊重雷姆斯（Remus），但我强烈反对。如果页面文件足够大，可以支持完全转储，则每次都会执行完全转储。如果你有一个非常大的内存量，这可能会导致一个微小的光点成为一个重大的停机

如果出现一次性暂时性问题，您不希望服务器必须向磁盘写入1 TB的RAM。如果存在重复出现的问题，可以增加页面文件以捕获完整转储。我会一直等到PSS（或有资格分析完整转储的其他人）要求您捕获完整转储时再这样做。极少数DBA知道如何分析完整转储。一个小型转储足以解决大多数突然出现的问题

另外，如果您的服务器配置为允许1 TB完全转储，并且出现重复性问题，您建议手头有多少可用磁盘空间？您可以在一个周末内填满整个SAN

页面文件1.5*RAM在您有幸拥有一台具有3或4 GB RAM的SQL Server的那些日子里是很常见的。现在已经不是这样了。我将页面文件保留为所有生产服务器上的Windows默认大小和设置（内存紧张的SSAS服务器除外）

---

为了澄清一下，我使用过从2GB内存到2GB内存的服务器。11年多之后，我只需增加分页文件就可以捕获一次完整转储。

在这种情况下，通常建议的1.5倍总物理RAM不是最好的。此非常一般性的建议是在假设所有内存都被“正常”进程使用的情况下提供的，这些进程通常可以将其使用最少的页面移动到磁盘，而不会对内存所属的应用程序进程产生大量性能问题

对于运行SQL Server的服务器（通常具有非常大的RAM），大部分物理RAM都提交给SQL Server进程，并且应该（如果配置正确）锁定在物理内存中，以防止将其调出到页面文件。SQL Server非常小心地管理自己的内存，并考虑到性能，使用分配给其进程的大部分RAM作为数据缓存来减少磁盘I/O。将这些数据缓存页分页到页面文件是没有意义的，因为将这些数据放在RAM中首先是为了减少磁盘I/O。（请注意，Windows操作系统同样使用可用RAM作为磁盘缓存来加速系统操作。）自SQ