适用于SQL Server的Windows O / S页面文件大小

Question

对于运行SQL Server的Windows 2003服务器，是否知道适当的页面文件大小有一个好的经验法则？

Answer 1

尽管尊重雷木思（我非常尊敬），但我强烈反对。如果页面文件足够大以支持完全转储，则每次都会执行完全转储。如果你有一个非常大的内存，这可能会导致一个小小的光点成为一个主要的中断。

如果存在一次性瞬态问题，您不希望服务器必须将1 TB的RAM写入磁盘。如果存在重复出现的问题，您可以增加页面文件以捕获完整转储。我会等到你被PSS（或其他有资格分析完全转储的人）请求你捕获一个完整的转储所困扰。极少数DBA知道如何分析完整转储。小型转储足以解决大多数问题。

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

页面文件1.5 * RAM是你很幸运拥有一台带有3或4 GB RAM的SQL Server的日子。事实并非如此。我将页面文件保留为所有生产服务器上的Windows默认大小和设置（遇到内存压力的SSAS服务器除外）。

只是为了澄清，我使用的服务器范围从2 GB RAM到2 TB RAM。超过11年后，我只需要增加页面文件来捕获一次完整转储。

Answer 2

与RAM的大小无关，您仍然需要一个至少是物理RAM量的1.5倍的页面文件。即使你有1 TB RAM机器也是如此，你需要在磁盘上使用1.5 TB的页面文件（听起来很疯狂，但确实如此）。

当进程通过VirtualAlloc / VirtualAllocEx询问MEM_COMMIT内存时，需要在页面文件中保留请求的大小。这在第一个Win NT系统中都是如此，今天仍然如此，请参阅Managing Virtual Memory in Win32：

  

当内存提交时，物理上   内存页面分配和   空间在页面文件中保留。

在极端奇怪的情况下，SQL Server将始终要求MEM_COMMIT页面。鉴于SQL使用Dynamic Memory Management策略预先保留尽可能多的缓冲池（保留和提交就VAS而言），SQL Server将在启动时请求大量预留页面文件中的空间。如果页面文件大小不正确，则错误801/802将开始显示在SQL的ERRORLOG文件和操作中。

这总是会引起一些混乱，因为管理员错误地认为大RAM不需要页面文件。事实恰恰相反，大型RAM增加了对页面文件的需求，这仅仅是因为Windows NT内存管理器的内部工作原理。希望保留的页面文件永远不会被使用。

Answer 3

据微软称，“随着计算机内存量的增加，对页面文件的需求也在减少。”然后，本文将介绍如何使用性能日志来确定页面文件的使用量是多少实际。尝试将页面文件设置为1.5X系统内存以便启动，然后执行建议的监视并从那里进行调整。

How to determine the appropriate page file size for 64-bit versions of Windows

Answer 4

越大越好，应用程序的工作集大小将开始进入递减收益。您可以尝试通过缓慢增加或减小大小来查找此值，直到您看到缓存命中率发生重大变化。但是，如果缓存命中率超过90％左右，那么你可能还可以。通常，您应该在生产系统上密切注意这一点，以确保它没有超出其RAM分配。

Answer 5

我们最近遇到了一些我们无法完全缩小的SQL Server性能问题，并且实际使用了我们的一个Microsoft支持服务单来帮助他们排除故障。出现了与SQL Server一起使用的最佳页面文件大小，微软的建议是 RAM的数量<1/1> 1/2 。

Answer 6

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

Answer 7

经过大量研究，我们在Windows 2003 Enterprise x64上运行Enterprise x64的专用SQL Server没有页面文件。

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

引用的MS文章并不认为该建议适用于运行开箱即用服务（如文件共享）的操作系统。

拥有一个页面文件只会给磁盘I / O带来负担，因为当只有SQL操作系统可以完成这项工作时，Windows正试图提供帮助。

Answer 8

在这种情况下，1.5倍物理RAM的正常建议并不是最好的。这个非常一般的建议是在假设所有内存正被＆＃34;正常＆＃34;使用的前提下提供的。进程，通常可以将最少使用的页面移动到磁盘，而不会为内存所属的应用程序进程产生大量性能问题。

对于运行SQL Server的服务器（通常具有非常大量的RAM），大多数物理RAM都提交到SQL Server进程，并且应该（如果配置正确）锁定在物理内存中，从而防止它被分页到页面文件。 SQL Server在考虑性能的情况下非常谨慎地管理自己的内存，使用分配给其进程的大部分RAM作为数据缓存来减少磁盘I / O.将这些数据缓存页面分页到页面文件是没有意义的，因为首先在RAM中拥有该数据的唯一目的是减少磁盘I / O. （请注意，Windows操作系统也使用可用的RAM与磁盘缓存类似，以加快系统操作。）由于SQL Server已经管理了自己的内存空间，因此不应将此内存空间视为＆＃34; pageable＆＃34;，而不包括在内在计算页面文件大小。

关于Remus提到的MEM_COMMIT，术语令人困惑，因为在虚拟内存中，＆＃34;保留＆＃34;从不参考实际分配，而是防止另一个进程使用地址空间（而不是物理空间）。内存可以＆＃34;承诺＆＃34;基本上等于物理RAM和页面文件大小的总和，并且执行MEM_COMMIT只会减少已提交池中的可用量。那时不在页面文件中分配匹配的页面。当实际写入已提交的内存页面时，即虚拟内存系统将分配物理内存页面并可能将另一个内存页面从物理RAM升级到页面文件。请参阅MSDN的VirtualAlloc function参考。

Windows操作系统会跟踪应用程序进程与其自身磁盘缓存机制之间的内存压力，并决定何时应将非锁定内存页面从物理页面缓存到页面文件。我的理解是，如果页面文件与实际的非锁定内存空间相比太大，可能会导致Windows过度地将应用程序内存分页到页面文件，从而导致这些应用程序遭受页面未命中的影响（性能降低）。 / p>

只要服务器没有运行其他需要大量内存的进程，页面文件大小应该足够4GB。如果您已将SQL Server设置为允许在内存中锁定页面，则还应考虑设置SQL Server的最大内存设置，以便为操作系统自身和其他进程留下一些物理RAM。

SQL Server中的802错误表明系统无法为数据缓存提交更多页面。增加页面文件大小只会在这种情况下有所帮助，因为Windows能够从非SQL Server进程中分页内存。在这种情况下允许SQL Server内存增长到页面文件中可能会消除错误消息，但由于之前关于数据缓存的原因，这是适得其反的。