配置SQL Server去使用 Windows的 Large-Page allocations

配置SQL Server去使用 Windows的 Large-Page allocations

看这篇文章之前可以先看一下下面这篇文章

虚拟内存,物理内存,页面文件,还有任务管理器一些概念的解释

了解一下虚拟地址空间(VirtualAddressSpace,VAS)的概念

 

 

前几天在论坛里遇到一个问题

问题地址:http://social.technet.microsoft.com/Forums/zh-CN/c55640f9-c216-4621-958a-3420e08f3f02/sql-server?forum=sqlserverzhchs

其中提到一个可能性的原因,开启了Large-Page allocations

Large-Page allocations是什么来头??

参考这篇文章:Configuring SQL Server to use Windows Large-Page allocations

 

今天,一个可改变控制的实现激使我去写这篇文章,这个可改变的控制就是允许运行在Windows200864位服务器上的SQLSERVER2005企业版上

使用跟踪标志834,SQLSERVER会利用 Large-Page allocations去构建内存中的Buffer Pool。

下面是我对 Large-Page allocations的理解和这个Large-Page allocations对性能的提升


页面分配

虚拟地址空间(VirtualAddressSpace,VAS)由很多的内存页面组成。这些页面有两种大小,小的页面只有4KB大小(IA64位系统上是8KB)

大的页面在64位系统上有2MB大小(IA64位系统上是16MB)。

虚拟地址空间(VirtualAddressSpace,VAS)是由页面描述符表这种结构来维护的,因此,每个虚拟地址空间在页面描述符表里都有对应页面表入口

(个人感觉类似于系统服务描述符表SSDT ,内核描述符表GDT/LDT)。硬件利用这个表将这些入口转译出可读的格式,无论什么时候转译一个虚拟地址,

都必须去这张表找虚拟地址的入口。为了加快查找表上这些入口的进程,CPU维护了一块缓存叫做:Translation Look-Aside Buffer (TLB)

TLB的工作方式类似于SQLSERVER的执行计划缓存,只要一个入口曾经被转译过下次就不需要再次转译。

 

知道这个,就很容易去理解大的页面和小的页面对性能的差别。当一个进程的虚拟地址空间(VirtualAddressSpace,VAS)(每个进程只有一个虚拟地址空间,

虚拟地址空间=一个进程使用的内存)是由小的内存页面构成的,那么在页面描述符表里的入口就需要相应增加,同时TLB缓存的入口数也会相应增加。

举个例子,有几个虚拟地址空间需要被缓存,使用小页面(一个页面4KB)就i需要在TLB中缓存更多的入口。更多的入口意味着无论什么时候接收到

一个新的转译请求,TLB的入口缓存就需要更多去循环利用。因此使用大页面去分配虚拟地址空间在性能上会有一定的提升。

 

大的页面2MB大小,小的页面4KB大小,比如一个进程需要8MB内存,那么需要4个大页面或者2000个小页面

所以使用小页面来分配虚拟地址空间,就需要在TLB缓存更多的入口,但是TLB缓存的大小是有限的!!

我个人对页面描述符表的理解:

配置SQL Server去使用 Windows的 Large-Page allocations

页面分配和SQLSERVER

就像我早前提到过的跟踪标志834,834跟踪标志会强迫SQLSERVER进程虚拟地址空间使用大页面去构建Buffer Pool。这个跟踪标志

只能在64位SQLSERVER企业版,并且需要开启 Lock Pages in Memory功能才能使用。

当SQLSERVER使用大页面分配的时候,在SQL服务启动时入口信息会被记录在SQL ERRORLOG里

Large Page Extensions enabled.
Large Page Granularity: 2097152
Large Page Allocated: 32MB
Using large pages for buffer pool.
10208 MB of large page memory allocated.

如果SQLSERVER帐户没有Lock Pages in Memory的权限,就会在SQL ERRORLOG里记录下错误信息

Cannot use Large Page Extensions: lock memory privilege was not granted.

这篇文章非常友好地阐述了大页面分配和阐述了需要使用64位SQLSERVER企业版不会使用大页面分配,除非使用跟踪标志834


 

注意:(1)不能在SQLSERVER运行的过程当中指定跟踪标志834

DBCC TRACEON(834,-1)

正在忽略跟踪标志 834。该跟踪标志无效,或者只能在服务器启动过程中指定。
DBCC 执行完毕。如果 DBCC 输出了错误信息,请与系统管理员联系。

只能在SQLSERVER启动的时候加上启动参数:834

 

(2)如果SQLSERVER的《max server memory》选项被设置为0,那么SQLSERVER会占用整个服务器的所有物理内存当SQLSERVER启动的时候

(3)服务器需要有8GB或以上的物理内存操作系统必须是企业版才能使用大页面分配

(4)可以使用下面SQL语句查看当前大页面分配的内存

SELECT  large_page_allocations_kb ,

        locked_page_allocations_kb

FROM    sys.dm_os_process_memory

配置SQL Server去使用 Windows的 Large-Page allocations

(5)如果系统符合大页面分配,并且开启了834跟踪标志,那么当SQLSERVER启动的时候会比较慢,可能需要几分钟时间

2009-06-04 14:20:31.14 Server      Large Page Allocated: 32MB 
2009-06-04 14:20:40.03 Server      Using large pages for buffer pool. 
2009-06-04 14:27:56.98 Server      2048 MB of large page memory allocated.

上面的时间显示SQLSERVER用了7分钟时间来分配页面

 

 

总结:

为什麽SQLSERVER启动的时候就占用了服务器的所有内存,其中的一个原因有可能是你开启了跟踪标志834符合SQLSERVER使用大页面

分配虚拟地址空间的要求,并且设置《max server memory》选项为0

 

相关文章

SQL Server and Large Pages Explained….

 

如有不对的地方,欢迎大家拍砖o(∩_∩)o 

 

2014-5-25补充

SQLSERVER2012新的内存管理器支持分配所有的大小。single page allocator和multi-page allocator都将退出历史舞台

不论分配多大的内存大小,内存管理器都只有三种不同的内存模型:

1、普通页

2、锁定页(locked pages,意思即是说通过设置组策略锁定内存页功能,把页面锁定在内存)

3、大内存页(large pages)

 

上面3种页面在SQLSERVER启动的时候ERROR LOG里都会打印出来,当前使用的是哪种模式的内存

 

大内存页只存在与64位版本中

1、新的内存管理器是完全支持NUMA的

2、虚拟地址空间的管理是完全动态的,特别是对32位的实例也是如此

3、内存管理器分配出去的内存都受max server memory控制

4、32位实例不再支持AWE

32位的SQLSERVER2012只能使用4GB物理内存,如果你需要使用更多的物理内存,必须要升级到64位版本

配置SQL Server去使用 Windows的 Large-Page allocations

 

 

你可能感兴趣的:(SQL Server)