淺談 SQL Server 記憶體管理 (三)：32/64 位元瓶頸、AWE、Lock Pages in Memory 與最佳實務

32 位元 SQL Server 記憶體天花板

32 位元進程虛擬位址空間 (VAS) 僅 4GB，系統預留 2GB，Buffer Pool 最高僅能使用 2GB。即便物理記憶體再大也無法突破。

突破方案一：/3GB 啟動參數 (Windows 2003) / BCDEdit increaseuserva (Windows 2008+)

將系統佔用從 2GB 降至 1GB，SQL Server 可用 VAS 增至 3GB。命令：

BCDEdit /set increaseuserva 3072

突破方案二：AWE (Address Window Extension)

透過 PAE (Physical Address Extension) 將 CPU 定址擴展至 36 位 (64GB)。啟用 AWE 後，Buffer Pool 中的 Data Cache 使用 AllocateUserPhysicalPages 分配「鎖定記憶體」，不被分頁至磁碟；MemToLeave 與 Plan Cache 仍用 VirtualAlloc。

兩大記憶體分配 API 差異

權限前置：Lock Pages in Memory (LPIM)

啟用 AWE 或 64 位元 LPIM 前，SQL Server 服務帳戶必須擁有「鎖定記憶體頁面」權限 (本機安全性原則 → 用戶權利指派)。否則啟動報錯：

設定方法：

64 位元 SQL Server 新挑戰：Buffer Pool Churn (抖動)

64 位元 VAS 巨大 (8TB/16TB)，理論無上限問題。但預設仍用 VirtualAlloc，記憶體壓力時頁面被交換出去，導致 Buffer Pool 頁面頻繁換入換出 (Churn)，產生大量 I/O。可透過 sys.dm_exec_query_memory_grants 觀察等待記憶體的查詢。

解決之道：啟用 Lock Pages in Memory (LPIM)

64 位元無需開啟 AWE，僅需授予 LPIM 權限，Buffer Pool Data Pages 即改用 AllocateUserPhysicalPages 分配，徹底杜絕 Churn。

LPIM 的雙面刃與應對

1. Windows 低記憶體無回應風險：SQL Server 鎖定大量記憶體，無法釋放回應 OS 低記憶體通知，可能導致 OS 不穩定甚至崩潰。
   • 對策：務必設定 Max Server Memory (留足 1-4GB 給 OS)，限制 Buffer Pool 上限。
2. 工作管理器顯示記憶體「縮水」假象：任務管理器僅顯示 Non-Data-Cache + MemToLeave (幾百 MB)，實際 Data Cache (幾十 GB) 不計入。
   • 對策：使用 PerfMon 監控 SQL Server:Memory Manager → Total Server Memory (KB) 計數器查看真實佔用。

總結：記憶體管理是效能調優基石

理解 VAS、Buffer Pool、MemToLeave、AWE/LPIM 機制，正確配置 Max Memory、LPIM、AWE，是解決 SQL Server I/O 瓶頸、穩定性問題的關鍵。許多看似 I/O 問題，根因往往在記憶體配置不當。