19

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

4

8 回答 8

14

尽管对 Remus（我非常尊重他）表示了应有的尊重，但我强烈反对。如果您的页面文件足够大以支持完整转储，则它将每次执行完整转储。如果你有大量的 RAM，这可能会导致一个小问题变成重大中断。

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

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

在您有幸拥有具有 3 或 4 GB RAM 的 SQL Server 的日子里，页面文件 1.5*RAM 是常态。现在不再是这种情况了。我将页面文件保留为所有生产服务器上的 Windows 默认大小和设置（遇到内存压力的 SSAS 服务器除外）。

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

于 2011-10-05T21:39:39.720 回答
13

与 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 内存管理器的内部工作原理。希望保留的页面文件从未使用过。

于 2009-11-22T22:11:18.923 回答
3

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

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

于 2010-08-03T18:58:10.880 回答
2

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

于 2008-12-23T14:45:57.940 回答
2

我们最近在我们的一个 SQL Server 中遇到了一些性能问题，我们无法完全缩小范围，实际上使用了我们的一张 Microsoft 支持票让他们帮助进行故障排除。与 SQL Server 一起使用的最佳页面文件大小出现了，Microsoft 的建议是它是RAM 量的 1 1/2 倍。

于 2009-09-10T05:05:52.373 回答
1

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

于 2008-08-11T12:22:31.097 回答
1

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

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

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

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

于 2011-05-24T12:47:26.453 回答
1

在这种情况下，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 函数参考。

Windows 操作系统跟踪应用程序进程和它自己的磁盘缓存机制之间的内存压力，并决定何时应该将非锁定内存页面从物理内存页面碰撞到页面文件。我的理解是，与实际的非锁定内存空间相比，拥有一个太大的页面文件可能会导致 Windows 过分热心地将应用程序内存分页到页面文件，从而导致这些应用程序遭受页面丢失的后果（性能缓慢）。

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

802 errors in SQL Server indicate that the system cannot commit any more pages for the data cache. Increasing the pagefile size will only help in this situation insofar as Windows is able to page out memory from non-SQL Server processes. Allowing SQL Server memory to grow into the pagefile in this situation might get rid of the error messages, but it is counterproductive, due to the point earlier about the reason for the data cache in the first place.

于 2014-04-03T23:51:13.013 回答