【发布时间】：2010-09-05 09:06:47
【问题描述】：
对于运行 SQL Server 的 Windows 2003 服务器的适当页面文件大小，是否有人知道一个好的经验法则？
【问题讨论】：
标签： sql-server windows
【发布时间】：2010-09-05 09:06:47
【问题描述】：
尽管对 Remus（我非常尊重他）表示应有的尊重，但我强烈反对。如果您的页面文件足够大以支持完整转储，则它将每次执行完整转储。如果你有大量的 RAM，这可能会导致一个小故障变成大中断。
如果存在一次性暂时性问题，您不希望您的服务器必须将 1 TB 的 RAM 写入磁盘。如果问题反复出现，您可以增加页面文件以捕获完整转储。我会等到您受到 PSS（或其他有资格分析完整转储的人）的指示，要求您捕获完整转储时再执行此操作。极少数 DBA 知道如何分析完整转储。一个小型转储足以解决大多数出现的问题。
另外，如果您的服务器配置为允许 1 TB 完全转储，并且经常出现问题，您建议手头有多少可用磁盘空间？您可以在一个周末填满整个 SAN。
在您有幸拥有具有 3 或 4 GB RAM 的 SQL Server 的日子里，页面文件 1.5*RAM 是常态。现在不再是这种情况了。我将页面文件保留为所有生产服务器上的 Windows 默认大小和设置（遇到内存压力的 SSAS 服务器除外）。
为了澄清起见，我使用的服务器的内存范围从 2 GB 到 2 TB 不等。 11 年多之后，我只需要增加页面文件即可捕获一次完整的转储。
【讨论】：
与 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 内存管理器的内部工作原理。希望保留的页面文件从未使用过。
【讨论】：
-
正是我想要的，谢谢！使用 32GB 的虚拟机，页面文件肯定会占用大量空间，但这似乎是野兽的本性……
根据 Microsoft 的说法，“随着计算机中 RAM 数量的增加，对页面文件的需求会减少。”然后，本文继续描述如何使用性能日志来确定页面文件实际使用了多少。尝试将您的页面文件设置为 1.5X 系统内存作为开始，然后进行推荐的监控并从那里进行调整。
How to determine the appropriate page file size for 64-bit versions of Windows
【讨论】：
根据应用程序工作集的大小，您将开始进入收益递减状态，越大越好。您可以尝试通过缓慢增加或减少大小来找到这一点，直到您看到缓存命中率发生显着变化。但是，如果缓存命中率超过 90% 左右，您可能就可以了。通常，您应该在生产系统上密切关注这一点，以确保它没有超出其 RAM 分配。
【讨论】：
我们最近在使用我们的一个 SQL Server 时遇到了一些性能问题，我们无法完全缩小范围，实际上我们使用了我们的一张 Microsoft 支持票来让他们帮助进行故障排除。提出了用于 SQL Server 的最佳页面文件大小，Microsoft 的建议是 RAM 量的 1 1/2 倍。
【讨论】：
如果您正在寻找高性能，您将希望完全避免分页，因此页面文件大小变得不那么重要。为数据库服务器投资尽可能多的 RAM。
【讨论】：
-
这其实是不正确的。如果不保留页面文件中的空间，则无法执行 MEM_COMMIT 分配。即使您有 1 TB 的 RAM，您的页面文件也必须至少是 RAM 量的 1.5 倍。
-
Remus，这不是真的，页面文件的规则 1.5*RAM 是推荐的，但不是必须的。如果 SQL Server 在具有大 RAM（超过 16GB）的 64 位计算机上，最好关闭页面文件，或者将页面文件设置为例如 4GB。绝对是错误的，如果你有 96GB 内存的机器，使用 144GB 页面文件，以防 SQL 服务器。我正在管理具有 16 到 96GB RAM 的机器上的数十个生产 SQL 服务器，而我的页面文件 = 4GB。
经过大量研究，我们在 Windows 2003 Enterprise x64 上运行 Enterprise x64 的专用 SQL Server 没有页面文件。
简单地说，页面文件是由操作系统管理的文件的缓存，SQL 有自己的内部内存管理系统。
引用的 MS 文章并不证明该建议适用于运行文件共享等开箱即用服务的操作系统。
拥有一个页面文件只会增加磁盘 I/O 的负担，因为 Windows 试图提供帮助，而只有 SQL 操作系统可以完成这项工作。
【讨论】：
在这种情况下，1.5 倍总物理 RAM 的正常建议并不是最好的。这个非常笼统的建议是在所有内存都被“正常”进程使用的假设下提供的，这些进程通常可以将其最少使用的页面移动到磁盘，而不会为内存所属的应用程序进程产生大量性能问题。
对于运行 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 function 参考。
Windows 操作系统会跟踪应用程序进程和它自己的磁盘缓存机制之间的内存压力，并决定何时应该将非锁定内存页面从物理内存页面推送到页面文件。我的理解是，与实际的非锁定内存空间相比，页面文件太大可能会导致 Windows 过分热心地将应用程序内存分页到页面文件，从而导致这些应用程序遭受页面丢失的后果（性能缓慢）。
只要服务器没有运行其他需要大量内存的进程，4GB 的页面文件大小就足够了。如果您已将 SQL Server 设置为允许在内存中锁定页面，则还应考虑设置 SQL Server 的最大内存设置，以便为操作系统和其他进程保留一些可用的物理 RAM。
SQL Server 中的 802 错误表明系统无法为数据缓存提交更多页面。增加页面文件大小只会在这种情况下有所帮助，因为 Windows 能够从非 SQL Server 进程中调出内存。在这种情况下允许 SQL Server 内存增长到页面文件中可能会消除错误消息，但会适得其反，因为前面提到了数据缓存的原因。
【讨论】：