為什麼SQL Server使用很少的記憶體？

昨天論壇裡邊看到一個文章，說SQL Server的記憶體一直上不去。從Task Schedule中看到SQL Server只使用了88MB記憶體，實際這台機器有12GB的記憶體，可用記憶體有超過8GB。

 

當時我以為是開啟了AWE導致的，所以串連到他的伺服器看了一下。但是資料庫為2005企業版64位，所以不用開啟AWE。而且即使開啟了，也會被忽略。

 

使用下面的指令碼查詢了一下SQL Server記憶體使用量：

 

select physical_memory_in_use_kb,locked_page_allocations_kb,*fromsys.dm_os_process_memory

 

看到實際使用的記憶體有2GB，遠遠超出工作管理員看到的。（也可以通過Perfmon的Total server memory（MB）查看）。

 

當時覺得很奇怪，查看了SQL Server錯誤記錄檔發現了類似下面的資訊：

 

2009-06-0412:21:08.16 Server Large Page Extensions enabled.
2009-06-04 12:21:08.16 Server Large Page Granularity: 2097152
2009-06-04 12:21:08.21 Server Large Page Allocated: 32MB

 

猜測這台期間開啟了Lock Pages In memory功能，之後得到確認。因為開啟Lock Pages In memory之後，SQL Server會使用AWE
APIs鎖定記憶體頁，所以這部分的記憶體使用量不會顯示在Working Set中。

 

 So in summary the AWE APIs for 32bit and 64bit SQL Server systems are used for different purposes. In 32bit it is really to extend memory access beyond 4Gb or to enable the AWE feature. For
64bit systems, it is to possibly gain performance and to “lock pages” for the buffer pool.

 

到現在這個問題就比較明朗了，其實SQL Server還是正常工作的。一般查詢SQL Server的使用還是建議使用DMV或者Perfmon，直接查看Working
Set資訊可能不準。

 

另外說一下，當時看到上面Large Page的資訊，以為是資料庫開啟了LargePage，但是使用DBCC TRACSTATUS查看沒有開啟834
Trace Flag,所以大資料功能是沒有啟用的。只有開啟834 Trace Flag資料庫才會真正啟用Large Page。

 

啟用Large page在資料庫錯誤記錄檔會看到類似資訊：

 

2009-06-0414:20:40.03 Server Using large pages for buffer pool.

 

關於Lock Pages In memory/working set機制我找到了兩篇文章，大家有興趣可以參考：

Funwith Locked Pages, AWE, Task Manager, and the Working Set

WhySQL Server is using so LESS memory