程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> 其他數據庫知識 >> 更多數據庫知識 >> 為什麼SQL Server使用很少的內存

為什麼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

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved