适用于 SQL Server 的 Windows 操作系统页面文件大小

Question

有谁知道运行 SQL Server 的 Windows 2003 服务器的适当页面文件大小的良好经验法则吗？

Answer 1

无论 RAM 大小如何，您仍然需要至少是物理 RAM 大小 1.5 倍的页面文件。即使您拥有 1 TB RAM 计算机，磁盘上也需要 1.5 TB 页面文件（听起来很疯狂，但确实如此），这也是事实。

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

当记忆时，分配内存的物理页面 和空间保留在页面文件中.

除了一些极端奇怪的情况，SQL Server 总是会请求 MEM_COMMIT 页。考虑到 SQL 使用的事实 动态内存管理 预先预留尽可能多的缓冲池的策略（预留和 提交 就VAS而言），SQL Server将在启动时请求页面文件中的大量保留空间。如果页面文件大小不正确，错误 801/802 将开始显示在 SQL 的 ERRORLOG 文件和操作中。

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

Answer 2

恕我直言，我非常尊重莱姆斯（Remus），但我强烈不同意。如果您的页面文件足够大以支持完整转储，则每次都会执行完整转储。如果您有大量 RAM，这可能会导致微小的故障变成严重的中断。

如果存在一次性瞬态问题，您不希望服务器必须将 1 TB RAM 写入磁盘。如果问题反复出现，您可以增加页面文件以捕获完整转储。我会等到 PSS（或有资格分析完整转储的其他人）指示您请求捕获完整转储后才执行此操作。只有极少数的 DBA 知道如何分析完整转储。小型转储足以解决大多数突然出现的问题。

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

在您幸运地拥有具有 3 或 4 GB RAM 的 SQL Server 的时代，页面文件 1.5*RAM 是标准配置。现在情况已不再如此。我在所有生产服务器上将页面文件保留为 Windows 默认大小和设置（遇到内存压力的 SSAS 服务器除外）。

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

Answer 3

根据微软的说法，“随着计算机中的RAM数量的增加，对页面文件的需求减少了。”然后，本文继续描述如何使用性能日志来确定页面文件的多少 实际上 正在使用。首先尝试将页面文件设置为 1.5 倍系统内存，然后进行建议的监控并从那里进行调整。

如何确定 64 位版本 Windows 的适当页面文件大小

Answer 4

应用程序工作集的大小越大越好，您将开始陷入收益递减的境地。您可以尝试通过缓慢增加或减少大小来找到这一点，直到看到缓存命中率发生显着变化。但是，如果缓存命中率超过 90% 左右，则可能没问题。一般来说，您应该在生产系统上密切关注这一点，以确保它没有超出其 RAM 分配。

Answer 5

最近，我们的 SQL Server 之一遇到了一些性能问题，我们无法完全缩小范围，实际上我们使用了一张 Microsoft 支持票证来让他们帮助解决问题。与 SQL Server 一起使用的最佳页面文件大小已经出现，Microsoft 的建议是 RAM 量的 1 1/2 倍.

Answer 6

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

Answer 7

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

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

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

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

Answer 8

在这种情况下，通常建议的总物理 RAM 的 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 的 虚拟分配函数 参考。

Windows 操作系统跟踪应用程序进程及其自己的磁盘缓存机制之间的内存压力，并决定何时应将非锁定内存页面从物理页面转移到页面文件。我的理解是，与实际的非锁定内存空间相比，页面文件太大可能会导致 Windows 过度地将应用程序内存调出到页面文件，从而导致这些应用程序遭受页面缺失的后果（性能缓慢）。

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

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