配置SQL Server去使用 Windows的 Large-Page/Huge-Page allocations
目录表->页表->物理内存页
看这篇文章之前可以先看一下下面这篇文章
了解一下虚拟地址空间（VirtualAddressSpace，VAS）的概念
前几天在论坛里遇到一个问题
其中提到一个可能性的原因，开启了Large-Page allocations，看完文章之后就会知道，其实跟Large-Page allocations无多大关系
Large-Page allocations是什么来头？？
参考这篇文章：Configuring SQL Server to use Windows Large-Page allocations
今天，一个可改变控制的实现激使我去写这篇文章，这个可改变的控制就是允许运行在Windows200864位服务器上的SQL Server 2005企业版上
使用跟踪标志834，SQLSERVER会利用 Large-Page allocations去构建内存中的Buffer Pool。
下面是我对 Large-Page allocations的理解和这个Large-Page allocations对性能的提升
页面分配
虚拟地址空间（VirtualAddressSpace，VAS）由很多的内存页面组成。这些页面有两种大小，32位系统是小的页面只有4KB大小（IA64位系统上是8KB）
64位系统上是大的页面有2MB大小（IA64位系统上是16MB）。
虚拟地址空间（VirtualAddressSpace，VAS）是由页面描述符表(简称页表)这种结构来维护的，因此，每个虚拟地址空间在页面描述符表里都有对应页面表入口
（个人感觉类似于系统服务描述符表SSDT ,内核描述符表GDT/LDT）。硬件利用这个表将这些入口转译出可读的格式，无论什么时候转译一个虚拟地址，
都必须去这张表找虚拟地址的入口。为了加快查找表上这些入口的速度，CPU维护了一块缓存叫做：Translation Look-Aside Buffer (TLB)
TLB的工作方式类似于SQLSERVER的执行计划缓存，只要一个入口曾经被转译过下次就不需要再次转译，大页的好处是提高TLB命中率，减少内核cpu消耗。
知道这个，就很容易去理解大的页面和小的页面对性能的差别。当一个进程的虚拟地址空间（VirtualAddressSpace，VAS）（每个进程只有一个虚拟地址空间，
虚拟地址空间=一个进程使用的内存）是由小的内存页面构成的，那么在页面描述符表里的入口就需要相应增加，同时TLB缓存的入口数也会相应增加。
举个例子，有几个虚拟地址空间需要被缓存，使用小页面(一个页面4KB)就需要在TLB中缓存更多的入口。更多的入口意味着无论什么时候接收到
一个新的转译请求，TLB的入口缓存就需要更多去循环利用。因此使用大页面去分配虚拟地址空间在性能上会有一定的提升。
大的页面2MB大小，小的页面4KB大小，比如一个进程需要8MB内存，那么需要4个大页面或者2000个小页面
所以使用小页面来分配虚拟地址空间，就需要在TLB缓存更多的入口，但是TLB缓存的大小是有限的！！
页面分配和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.
这篇文章非常友好地阐述了大页面分配和阐述了需要使用跟踪标志834 并使用64位SQLSERVER企业版才能使用大页面分配
注意：（1）不能在SQLSERVER运行的过程当中指定跟踪标志834
DBCC TRACEON(834,-1)
正在忽略跟踪标志 834。该跟踪标志无效，或者只能在服务器启动过程中指定。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
只能在SQLSERVER启动的时候加上启动参数：834
（2）如果SQLSERVER的《max server memory》选项被设置为0，当SQLSERVER启动的时候会占用整个服务器的所有物理内存
（3）服务器需要有8GB或以上的物理内存和操作系统并且必须是企业版才能使用大页面分配
（4）可以使用下面SQL语句查看当前大页面分配的内存
SELECT large_page_allocations_kb , locked_page_allocations_kb FROM sys.dm_os_process_memory
（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….
http://www.cnblogs.com/MYSQLZOUQI/p/5335649.html
如有不对的地方，欢迎大家拍砖o(∩_∩)o
2014-5-25补充
SQLSERVER2012新的内存管理器支持分配所有的大小。single page allocator和multi-page allocator都将退出历史舞台
不论分配多大的内存大小，内存管理器都只有三种不同的内存模型：
1、普通页
2、锁定页（locked pages，意思即是说通过设置组策略锁定内存页功能，把页面锁定在内存）
3、大内存页（large pages）
上面3种页面在SQLSERVER启动的时候ERROR LOG里都会打印出来，当前使用的是哪种模式的内存
大内存页的使用只存在于64位版的SQL Server中
1、新的内存管理器是完全支持NUMA的
2、虚拟地址空间的管理是完全动态的，特别是对32位的实例也是如此
3、内存管理器分配出去的内存都受max server memory控制
4、32位实例不再支持AWE
32位的SQLSERVER2012只能使用4GB物理内存，如果你需要使用更多的物理内存，必须要升级到64位版本
实际上，跑在Linux上的Oracle也有这个问题，在Linux上开启huge page/large page的方法
1、/etc/sysctl.cnf 中增加vm.nr_hugepages参数来为大页设定一个合理的值，值的单位为2MB，需要重启Linux
2、echo 一个值到/proc/sys/vm/nr_hugepages中也可以临时性的对大页进行设定
具体参考：http://mp.weixin.qq.com/s?__biz=MzI4NTA1MDEwNg==&mid=403265328&idx=1&sn=b852e6ba4669c787de352c9823d05139&scene=0#wechat_redirect
本文版权归作者所有，未经作者同意不得转载。