SQL Server 2000記憶體管理內幕

Introduction

在這篇專欄裡，我們將從開發人員的角度來探討SQL Server記憶體管理內幕。就是說，我們將討論SQL Server使用API和作業系統功能管理記憶體的方式及其工作原理。通過這種方式探討一個產品，將有助於我們理解產品開發人員的思路，以及他們所設計的使用方法。理解一個產品的工作原理和它的設計用途，是掌握這個產品的關鍵。

我們將從一些基礎的Windows記憶體管理基本原理介紹開始。和所有的32位Windows應用程式一樣，SQL Server使用Windows記憶體管理功能分配、釋放、管理記憶體資源。正如所有其它的Windows應用程式，SQL Server調用Win32記憶體管理API函數，與作業系統提供的記憶體資源進行互動。

由於SQL Server中幾乎所有的記憶體配置都使用虛擬記憶體（不是記憶體堆），因此絕大部分記憶體配置代碼最終都是通過調用Win32的VirtualAlloc或者是VirtualFree函數完成。SQL Server調用VirtualAlloc保留、提交分配的虛擬記憶體，調用VirtualFree釋放虛擬記憶體。

Virtual Memory vs Physical Memory

在x86系列處理器上，Windows為所有進程提供一個4GB虛擬記憶體工作空間。用"虛擬"這個詞，意思是這個記憶體並不是通常意義上的記憶體，它只是一個位址範圍，並沒有和實體儲存體單元關聯在一起。當進程請求記憶體配置時，這些地址空間才被使用，和具體的實體儲存體單元關聯起來。然而這些實體儲存體單元並不一定是實體記憶體，它通常可能會是磁碟空間，確切的說，是作業系統的分頁檔案（System Paging Files）。這就是為什麼多個應用程式可以同時運行在一個128M記憶體的系統上，每個應用程式都有一個4GB的虛擬記憶體地址空間－－它不是真正的記憶體，但對應用程式來說可以理解為記憶體。Windows透明的處理paging files的資料拷貝，以使應用程式能夠使用的記憶體可以超過機器的實際實體記憶體，並使應用程式能夠公平的存取機器的實體記憶體。

這個4GB的地址空間被分成兩部分：user mode部分和kernal mode部分。預設情況下，每個部分的大小為2GB，在Windows NT系列的作業系統上，可以通過BOOT.INI中的開關來改變這個預設設定（Windows NT, Windows 2000, Windows XP和Windows Server 2003屬於Windows NT系列，Windows 9x和Windows ME不屬於）。

圖1：Windows將進程的虛擬位址空間分成user mode（應用程式）和kernal mode（作業系統）兩個部分

每個應用程式擁有自己的虛擬記憶體地址空間，但作業系統和裝置驅動程式共用同一個私人地址空間。每一個虛擬記憶體頁（memory page）都和特定的處理器模式（processor mode）相關聯，為了存取某個虛擬記憶體頁，處理器必須工作在要求的模式下。這意味著應用程式不能直接存取kernal mode的虛擬記憶體，系統必須切換到kernal mode才能存取kernal mode的記憶體空間。

Application Memory Tuning

3GB啟動選項（Windows 2000的Advanced Server和DataCenter及後續Windows版本中可用）允許改變這兩個地址空間部分的預設大小。它允許將進程的user mode地址空間從2GB擴充到3GB，相應的代價是kernal mode的地址空間從2GB減小到1GB。用Windows的說法，這個功能叫做Application Memory Tuning或者是4GB Tuning（4GT）。你可以通過在BOOT.INI檔案的[Operating Systems]部分添加/3GB開關啟用應用Application Memory Tuning。通常情況下，人們通過設定BOOT.INI檔案的[Operating Systems]部分，將系統配置為可以使用3GB或者不使用3GB啟動，以使在系統啟動時可以進行選擇。

警告：你也可以在Windows 2000 Professional和Windows 2000 Server上使用/3GB開關，這樣做的負面結果是，將kernal mode的空間減小到了1GB，但並不會增加user mode的空間。換句話說，你減小了kernal mode的空間但並沒有獲得任何好處。

注意：Windows XP和Windows Server 2003引入了一個新的啟動選項/USERVA，和/3GB一起使用，比單獨使用/3GB能夠更好的控制。你在BOOT.INI中添加/3GB的時候可以同時添加/USERVA，/USERVA比單獨使用/3GB的優點是它允許你指定一個準確的地址空間大小值供user mode存取。例如，/USERVA=2560為user mdoe配置2.5G的空間，剩餘的1.5G用於kernal mode。上面的警告資訊在使用/USERVA選項時同樣適用。

Large-Address-Aware Executables

在/3GB支援加入Windows之前，應用程式無法使用指標的最高位，User mode的應用程式只能夠對32位指標的前31位表示的地址空間進行存取。對於剩下的1位，一些聰明的開發人員不希望浪費進程空間裡的這1個位，把它用於了其它的目的，例如用於標識那些應用程式特定的地址配置類型的指標。這在引入/3GB後帶來一個難題，因為這種類型的應用程式無法區分引用2GB以上記憶體的指標，和那些引用2GB以下記憶體但是最高位由於其它原因而被設定的指標。基本上，使用/3GB啟動機器，會使這樣的應用程式崩潰。為瞭解決這個問題，微軟在Win32 PE檔案格式（定義Windows下可執行檔Exe和Dll結構的格式）的Characteristics欄位加入一個新標識位的支援，用於指示應用程式是否支援大的定址能力。設定可執行檔頭中Characteristics欄位的第32位啟用IMAGE_FILE_LARGE_ADDRESS_AWARE標識位。通過設定應用程式頭的這個標識位，表明應用程式能夠處理那些最高位被設定的指標，不會由於這個位帶來任何多意性。當設定了這個標識位，在正確的Windows版本上使用/3GB選項啟動，系統將為進程提供一個私人的擴充user mode地址空間。你可以使用DumpBin、ImageCfg等可以分析可執行檔頭的工具，查看應用程式是否啟用了這個標識位。Visual C++通過/LARGEADDRESSAWARE串連開關提供對IMAGE_FILE_LARGE_ADDRESS_AWARE的支援。SQL Server啟用了這個標識位，因此當你在正確的Windows版本上使用/3GB開關啟動，系統將擴充SQL Server的user mode地址空間。

注意：Windows在進程啟動時檢查IMAGE_FILE_LARGE_ADDRESS_AWARE標識，忽略Dll的標識。對那些最高位被設定的指標，dll代碼必須能夠正確處理。