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

虛擬內(nèi)存，物理內(nèi)存，頁面文件，還有任務管理器一些概念的解釋

了解一下虛擬地址空間（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

今天，一個可改變控制的實現(xiàn)激使我去寫這篇文章，這個可改變的控制就是允許運行在Windows200864位服務器上的SQLSERVER2005企業(yè)版上

使用跟蹤標志834，SQLSERVER會利用Large-Page allocations去構(gòu)建內(nèi)存中的Buffer Pool。

下面是我對Large-Page allocations的理解和這個Large-Page allocations對性能的提升

頁面分配

虛擬地址空間（VirtualAddressSpace，VAS）由很多的內(nèi)存頁面組成。這些頁面有兩種大小，小的頁面只有4KB大小（IA64位系統(tǒng)上是8KB）

大的頁面在64位系統(tǒng)上有2MB大小（IA64位系統(tǒng)上是16MB）。

虛擬地址空間（VirtualAddressSpace，VAS）是由頁面描述符表這種結(jié)構(gòu)來維護的，因此，每個虛擬地址空間在頁面描述符表里都有對應頁面表入口

（個人感覺類似于系統(tǒng)服務描述符表SSDT ,內(nèi)核描述符表GDT/LDT）。硬件利用這個表將這些入口轉(zhuǎn)譯出可讀的格式，無論什么時候轉(zhuǎn)譯一個虛擬地址，

都必須去這張表找虛擬地址的入口。為了加快查找表上這些入口的進程，CPU維護了一塊緩存叫做：Translation Look-Aside Buffer (TLB)

TLB的工作方式類似于SQLSERVER的執(zhí)行計劃緩存，只要一個入口曾經(jīng)被轉(zhuǎn)譯過下次就不需要再次轉(zhuǎn)譯。

知道這個，就很容易去理解大的頁面和小的頁面對性能的差別。當一個進程的虛擬地址空間（VirtualAddressSpace，VAS）（每個進程只有一個虛擬地址空間，

虛擬地址空間=一個進程使用的內(nèi)存）是由小的內(nèi)存頁面構(gòu)成的，那么在頁面描述符表里的入口就需要相應增加，同時TLB緩存的入口數(shù)也會相應增加。

舉個例子，有幾個虛擬地址空間需要被緩存，使用小頁面(一個頁面4KB)就i需要在TLB中緩存更多的入口。更多的入口意味著無論什么時候接收到

一個新的轉(zhuǎn)譯請求，TLB的入口緩存就需要更多去循環(huán)利用。因此使用大頁面去分配虛擬地址空間在性能上會有一定的提升。

大的頁面2MB大小，小的頁面4KB大小，比如一個進程需要8MB內(nèi)存，那么需要4個大頁面或者2000個小頁面

所以使用小頁面來分配虛擬地址空間，就需要在TLB緩存更多的入口，但是TLB緩存的大小是有限的！！

我個人對頁面描述符表的理解：

頁面分配和SQLSERVER

就像我早前提到過的跟蹤標志834，834跟蹤標志會強迫SQLSERVER進程虛擬地址空間使用大頁面去構(gòu)建Buffer Pool。這個跟蹤標志

只能在64位SQLSERVER企業(yè)版，并且需要開啟Lock Pages in Memory功能才能使用。

當SQLSERVER使用大頁面分配的時候，在SQL服務啟動時入口信息會被記錄在SQL ERRORLOG里

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

如果SQLSERVER帳戶沒有Lock Pages in Memory的權(quán)限，就會在SQL ERRORLOG里記錄下錯誤信息

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

這篇文章非常友好地闡述了大頁面分配和闡述了需要使用64位SQLSERVER企業(yè)版不會使用大頁面分配，除非使用跟蹤標志834

注意：（1）不能在SQLSERVER運行的過程當中指定跟蹤標志834

DBCC TRACEON(834,-1)

正在忽略跟蹤標志 834。該跟蹤標志無效，或者只能在服務器啟動過程中指定。DBCC 執(zhí)行完畢。如果 DBCC 輸出了錯誤信息，請與系統(tǒng)管理員聯(lián)系。

只能在SQLSERVER啟動的時候加上啟動參數(shù)：834

（2）如果SQLSERVER的《max server memory》選項被設(shè)置為0，那么SQLSERVER會占用整個服務器的所有物理內(nèi)存當SQLSERVER啟動的時候

（3）服務器需要有8GB或以上的物理內(nèi)存和操作系統(tǒng)必須是企業(yè)版才能使用大頁面分配

（4）可以使用下面SQL語句查看當前大頁面分配的內(nèi)存

SELECT  large_page_allocations_kb ,        locked_page_allocations_kbFROM    sys.dm_os_process_memory

（5）如果系統(tǒng)符合大頁面分配，并且開啟了834跟蹤標志，那么當SQLSERVER啟動的時候會比較慢，可能需要幾分鐘時間

2009-06-04 14:20:31.14 Server Large Page Allocated: 32MB2009-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分鐘時間來分配頁面

總結(jié)：

為什麼SQLSERVER啟動的時候就占用了服務器的所有內(nèi)存，其中的一個原因有可能是你開啟了跟蹤標志834符合SQLSERVER使用大頁面

分配虛擬地址空間的要求，并且設(shè)置《max server memory》選項為0

相關(guān)文章

SQL Server and Large Pages Explained….

如有不對的地方，歡迎大家拍磚o(∩_∩)o

2014-5-25補充

SQLSERVER2012新的內(nèi)存管理器支持分配所有的大小。single page allocator和multi-page allocator都將退出歷史舞臺

不論分配多大的內(nèi)存大小，內(nèi)存管理器都只有三種不同的內(nèi)存模型：

1、普通頁

2、鎖定頁（locked pages，意思即是說通過設(shè)置組策略鎖定內(nèi)存頁功能，把頁面鎖定在內(nèi)存）

3、大內(nèi)存頁（large pages）

上面3種頁面在SQLSERVER啟動的時候ERROR LOG里都會打印出來，當前使用的是哪種模式的內(nèi)存

大內(nèi)存頁只存在與64位版本中

1、新的內(nèi)存管理器是完全支持NUMA的

2、虛擬地址空間的管理是完全動態(tài)的，特別是對32位的實例也是如此

3、內(nèi)存管理器分配出去的內(nèi)存都受max server memory控制

4、32位實例不再支持AWE

32位的SQLSERVER2012只能使用4GB物理內(nèi)存，如果你需要使用更多的物理內(nèi)存，必須要升級到64位版本