当前位置: 首页>>技术解读>>正文


Windows 2008R2上SQL 2008R2的推荐页面文件大小

webfans 技术解读 , , , , 去评论

问题描述

此Microsoft文章 – How to determine the appropriate page file size for 64-bit versions of Windows Server 2008 and or Windows 2008 R2提供了计算64位Windows 2008和Windows 2008R2的页面文件大小的指南。这无疑适用于通用服务器。我想知道在Windows 2008 /R2 64位上运行SQL Server 2008R2的指导是什么?

我假设我们希望在内存数据中尽可能少地访问页面文件,否则SQL可能会在数据中两次访问磁盘。 SQL Server是否甚至允许内存中的数据命中页面文件?我已经通过SQL Server 2008 R2 Books Online寻求指导,但尚未发现任何页面文件的使用。

这是一个潜在的使用场景:给定一个64GB RAM的物理服务器,是整个64GB RAM所需的页面文件吗?我们应该为96GB的页面文件做好准备吗?对于单个文件来说,这似乎有点过分。我知道传统的观点是Windows将页面文件耦合到内存以试图在RAM上更容易地交换应用程序,但这是真的吗?一个小于64GB的页面文件会阻碍性能吗?

最佳解决思路

SQL Server没有特殊设置,只能正常使用物理内存

就像MS对Windows所说的那样,就是这样

哦,无论如何我们购买更多内存,而我们只是一个主题… 😉

次佳解决思路

查看lock pages in memory。这样,您可以优先使用SQL服务帐户来使用可用的RAM而不是分页到磁盘。要阅读内存中锁定页面的更多信息,请检查此link。摘录如下:

The Windows policy Lock Pages in Memory option is disabled by default. This privilege must be enabled to configure Address Windowing Extensions (AWE). This policy determines which accounts can use a process to keep data in physical memory, preventing the system from paging the data to virtual memory on disk. On 32-bit operating systems, setting this privilege when not using AWE can significantly impair system performance. Locking pages in memory is not required on 64-bit operating systems.

请在使用系统之前测试此功能。

第三种解决思路

是的,对于64GB RAM,您需要至少64GB交换文件(建议96GB)。不是因为潜在的交换,而是因为Windows内存管理器的设计。我之前在System pagefile size on machines with large RAM中写过这个问题:

When a process asks for MEM_COMMIT memory via VirtualAlloc/VirtualAllocEx, the requested size needs to be reserved in the pagefile. This was true in the first Win NT system, and is still true today see Managing Virtual Memory in Win32:

When memory is committed, physical pages of memory are allocated and space is reserved in a pagefile.

替代方案类似于oom_killer

因此,请遵循建议,有时事情比他们看起来更复杂。我甚至没有触及AWE带来的复杂性和锁页特权……

参考资料

本文由朵颐IT整理自网络, 文章地址: https://duoyit.com/article/3031.html,转载请务必附带本地址声明。