对于运行SQL Server的Windows 2003服务器，适当的页面文件大小是否有一个好的经验法则？
RAM的大小不相关，你仍然需要一个页面文件至少1.5倍的物理RAM的数量。 即使你有一个1TB的RAM机器，你也需要1.5TB的页面文件（听起来很疯狂，但是是真的）。
当进程通过VirtualAlloc / VirtualAllocEx询问MEM_COMMIT内存时，请求的大小需要在页面文件中保留。 这在第一个Win NT系统中是真实的，今天仍然如此，请参阅在Win32中管理虚拟内存 ：
当提交内存时，将分配内存的物理页面， 并在页面文件中保留空间 。
在一些极端奇怪的情况下，SQL server将总是要求MEM_COMMIT页面。 考虑到SQL使用动态内存管理策略，尽可能多地保留缓冲池（按照VAS预留和提交 ），SQL server将在启动页面文件时启动一个巨大的空间保留请求。 如果页面文件大小错误，错误801/802将开始显示在SQL的ERRORLOG文件和操作中。
这总会造成一些混淆，因为管理员错误地认为大内存不需要页面文件。 实际上恰恰相反，只是由于Windows NT内存管理器的内部工作原因，大量的RAM增加了页面文件的需求。 保留页面文件，希望，从来没有使用过。
对于Remus（我非常尊重他）的尊重，我强烈反对。 如果您的页面文件足够大以支持完整转储，则每次都会执行完整转储。 如果你有一个非常大量的内存，这可能会导致一个微小的昙花一现，成为一个重大的中断。
如果存在一次性瞬态问题，则不希望服务器必须将1 TB的RAM写入磁盘。 如果存在反复出现的问题，则可以增加页面文件以捕获完整转储。 我会等待这样做，直到您被PSS（或其他有资格分析完整转储）的用户请求捕获完整转储为止。 一小部分DBA知道如何分析完整的转储。 小型转储足以解决大多数弹出的问题。
此外，如果您的服务器配置为允许1TB的完全转储，并且会出现一个反复出现的问题，那么您推荐的可用磁盘空间有多少？ 您可以在一个周末填写整个SAN。
一个页面文件1.5 * RAM是在你有幸拥有一个带有3或4 GB RAM的SQL server的日子里的标准。 现在不是这样了。 我将所有生产服务器上的Windows默认大小和设置保留为页面文件（除了存在内存压力的SSAS服务器外）。
为了澄清，我已经使用了从2 GB RAM到2 TB RAM的服务器。 超过11年后，我只需增加分页文件即可捕获一次完整的转储。
据微软称，“随着计算机内存容量的增加，对页面文件的需求也在减少。” 本文继续介绍如何使用性能日志来确定页面文件的实际使用量。 尝试将您的页面文件设置为1.5X系统内存，然后执行建议的监视并从那里进行调整。
如何为64位版本的Windows确定适当的页面文件大小
在应用程序工作集的大小上越大越好，您将开始进入收益递减。 您可以尝试通过缓慢增大或减小大小来查找，直到看到缓存命中率发生显着变化。 但是，如果缓存命中率超过90％左右，您可能就可以。 一般来说，您应该在生产系统上关注这个问题，以确保它没有超出内存分配。
我们最近遇到了一些我们无法完全缩小的SQL server性能问题，并且实际使用了我们的Microsoft支持服务单中的一个来帮助他们排除故障。 用于SQL server的最佳页面文件大小出现了，微软的建议是它的内存容量的1.5倍 。
如果你正在寻找高性能，你会想要完全避免分页，所以页面文件的大小变得不太重要。 为数据库服务器投入尽可能多的RAM。
经过大量研究，我们在Windows 2003 Enterprise x64上运行Enterprise x64的专用SQL server没有页面文件。
简单地说，页面文件是由OS管理的文件的缓存，而SQL有自己的内部内存管理系统。
引用的MS文章没有限定该建议适用于运行诸如文件共享之类的开箱即用服务的操作系统。
有一个页面文件简单地负担磁盘I / O，因为Windows正试图帮助，当只有SQL操作系统可以完成这项工作。
在这种情况下，1.5倍总物理内存的正常建议不是最好的。 这个非常一般的建议是在假设所有内存被“正常”进程使用的情况下提供的，这些进程通常可以将其最少使用的页面移动到磁盘上，而不会为内存所属的应用进程产生大量的性能问题。
对于运行SQL server的服务器（通常具有非常大量的RAM），大多数物理RAM被提交到SQL server进程，并且应该（如果配置正确的话）锁定在物理内存中，防止它被分页到页面文件。 SQL server非常小心地管理自己的内存，考虑到性能，将分配给其进程的大部分RAM用作数据缓存来减少磁盘I / O。 将这些数据缓存页面分页到页面文件是没有意义的，因为将RAM中的数据放在首位的唯一目的是减少磁盘I / O。 （请注意，Windows操作系统也像磁盘缓存一样使用可用RAM来加速系统操作。）由于SQL server已经管理自己的内存空间，因此该内存空间不应被视为“可分页”，并且不会包含在页面文件的计算中尺寸。
关于Remus提到的MEM_COMMIT，术语是混淆的，因为在虚拟存储器的说法中，“保留”从来不指实际的分配，而是防止另一个进程使用地址空间（而不是物理空间）。 可用于“提交”的内存基本上等于物理RAM和页面文件大小的总和，并且执行MEM_COMMIT只是减少了提交池中可用的数量。 它当时不会在页面文件中分配一个匹配的页面。 实际写入提交的内存页面时，即虚拟内存系统将分配物理内存页面，并可能将另一个内存页面从物理RAM中撞到页面文件。 请参阅MSDN的VirtualAlloc函数参考。
Windows操作系统跟踪应用程序进程和自己的磁盘缓存机制之间的内存压力，并决定何时将非锁定的内存页面从物理页面冲突到页面文件。 我的理解是，与实际的非锁定内存空间相比，页面文件太大会导致Windows过度地将应用程序内存分页到页面文件，导致这些应用程序遭受页面遗漏（性能下降）的后果。
只要服务器没有运行其他需要内存的进程，4GB的页面文件大小应该足够了。 如果您已经将SQL server设置为允许在内存中锁定页面，则还应该考虑设置SQL server的最大内存设置，以便为操作系统本身和其他进程留出一些物理内存。
SQL server中的802错误表明系统无法为数据缓存提交更多页面。 只要Windows能够从非SQL server进程分页内存，增加页面文件的大小只会有助于这种情况。 在这种情况下允许SQL server内存增长到页面文件中，可能会摆脱错误消息，但由于数据缓存的原因早就出现，这样做会适得其反。