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

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

0
额外 编辑
意见: 3

8 答案

我们最近遇到了一些SQL Server的性能问题,我们无法完全缩小范围,并且实际上使用了我们的Microsoft支持票据之一来帮助他们排除故障。用于SQL Server的最佳页面文件大小出现了,微软的建议是它是<1/2的RAM数量。

0
额外

RAM的大小无关,你仍然需要一个页面文件至少1.5倍的物理内存。即使你有一个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内存管理器的内部工作原因,大内存增加了页面文件的需求。希望保留的页面文件不会被使用。

0
额外
正是我期待的,谢谢!有了一个32GB的虚拟机,页面文件确实占用了很多空间,看起来像野兽的性质,但是......
额外 作者 tsquillario,

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

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

0
额外

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

0
额外

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

0
额外
这实际上是不正确的。如果不保留页面文件中的空间,MEM_COMMIT分配将无法兑现。即使您有1 TB的RAM,您的页面文件也必须至少为RAM数量的1.5倍。
额外 作者 Remus Rusanu,

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

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

引用的MS文章没有限定该建议适用于运行诸如文件共享之类的开箱即用服务的操作系统。

有一个页面文件简单地加载了磁盘I / O,因为Windows正在尝试提供帮助,只有SQL OS可以完成这项工作。

0
额外

尽管对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年后,我只需增加分页文件即可捕获一次全部转储。

0
额外

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

对于运行SQL Server的服务器(通常具有非常大量的RAM),大部分物理RAM都被提交给SQL Server进程,并且应该(如果配置正确)锁定在物理内存中,防止它被分页出页面文件。 SQL Server会非常仔细地管理自己的内存,并将性能考虑在内,将分配给其进程的大部分内存用作数据缓存以减少磁盘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。

SQL Server中的802错误表明系统无法为数据缓存提交更多页面。只要Windows能够从非SQL Server进程中分出内存,增加页面文件大小只会有助于这种情况。在这种情况下允许SQL Server内存增长到页面文件中,可能会摆脱错误消息,但由于数据缓存的原因早就提到了这一点,它会起反作用。

0
额外