SQL Server内存架构基础

时间:2024-05-22 11:38:52

 

翻译自:

https://mssqlwiki.com/sqlwiki/sql-performance/basics-of-sql-server-memory-architecture/

 

1.    32SQL Server内存架构

 

Win32内存架构里,每个进程有4GB的虚拟地址空间。默认情况下,2GB的地址空间可从用户模式访问(应用程序像SQL Server),剩下的2GB可从内核模式访问。

 

所以,在32Windows架构里,SQL Server最大可用内存为2GB

注意:当/3GB开关启用后,用户模式地址空间变为3GB,而内核模式变为1GB。当32SQL Server运行在64Windows下(WOW64),它获得4GB的用户地址空间。它也可以在WOW64模式下影响AWE,并可以使用多于4GB内存。

 

SQL Server内存架构基础


SQL Server“用户地址空间(User address space)”分为两个部分:MemToleaveBuffer Pool

 

MemToLeave(MTL)Buffer Pool(BPool)的大小由SQLServer在启动时决定,如下:

MTL(Memory to Leave) = (Stack size * max worker threads) +Additional space(By default 256 MB and can be controlled by -g)

Stack size = 512 KB per thread for 32 Bit SQL Server

I.e = (256 * 512KB) + 256MB = 384MB

 

加载DLL的额外空间从SQL Server 2000开始为256MB。该空间用于存储:

  1.        COM对象

  2.        扩展存储过程

  3.        进程中加载的链接服务器的内存分配或者在SQL Server进程中其他DLL的加载

  4.        SQL Server内存管理器的内存分配,如果分配大小大于8K需要持续内存(Multiple_pages_kb)。

  5.        SQLCLR

注意,加载DLL的额外空间可以使用-g启动参数修改。

在任何机器上,使用少于4个处理器时,最大工作线程(Maximum worker Thread)默认总是为256MB(除非,我们使用sp_configure修改该值)。

 

SQL Server Buffer Pool为“Phyiscal RAM”和“user modememory(2GB or 3GB) - MTL”的最小值- BUF structures

BPool = Minimum(Physical memory, User address space – MTL) –BUF structures

 

为了确保MemToLeave持续分配,SQL Server首先保留MTL,然后是所有的Buffer Pool区域,最后释放MemToLeave区域。

 

BPOOL中是什么?


数据页/索引页和SQL Server内存管理器分配的内存,用于以下memory clerk之一。如果内存请求<=8KB

 

CACHESTORE_PHDR 
CACHESTORE_XMLDBTYPE 
CACHESTORE_EVENTS 
MEMORYCLERK_SQLSTORENG 
MEMORYCLERK_XE 
CACHESTORE_XPROC 
OBJECTSTORE_SNI_PACKET 
CACHESTORE_BROKERRSB 
OBJECTSTORE_SERVICE_BROKER 
MEMORYCLERK_SQLSERVICEBROKERTRANSPORT 
MEMORYCLERK_XE_BUFFER 
CACHESTORE_XMLDBATTRIBUTE 
MEMORYCLERK_SQLOPTIMIZER 
USERSTORE_OBJPERM 
USERSTORE_TOKENPERM 
CACHESTORE_FULLTEXTSTOPLIST 
MEMORYCLERK_SQLGENERAL 
MEMORYCLERK_SQLHTTP 
CACHESTORE_NOTIF 
CACHESTORE_XMLDBELEMENT 
OBJECTSTORE_LOCK_MANAGER 
MEMORYCLERK_SQLBUFFERPOOL 
MEMORYCLERK_SQLSOAP 
MEMORYCLERK_TRACE_EVTNOTIF 
CACHESTORE_CONVPRI 
MEMORYCLERK_QSRANGEPREFETCH 
CACHESTORE_BROKERREADONLY 
MEMORYCLERK_SQLCLRASSEMBLY 
MEMORYCLERK_SOSNODE 
CACHESTORE_STACKFRAMES 
MEMORYCLERK_SQLCONNECTIONPOOL 
MEMORYCLERK_SQLSERVICEBROKER 
CACHESTORE_OBJCP 
MEMORYCLERK_SQLQUERYPLAN 
OBJECTSTORE_SECAUDIT_EVENT_BUFFER 
OBJECTSTORE_LBSS 
MEMORYCLERK_FULLTEXT 
CACHESTORE_TEMPTABLES 
CACHESTORE_BROKERTBLACS 
MEMORYCLERK_SQLXML 
USERSTORE_SXC 
MEMORYCLERK_BHF 
CACHESTORE_SQLCP 
CACHESTORE_SYSTEMROWSET 
USERSTORE_SCHEMAMGR 
MEMORYCLERK_SQLQUERYCOMPILE 
CACHESTORE_BROKERTO 
CACHESTORE_BROKERKEK 
MEMORYCLERK_SNI 
MEMORYCLERK_FULLTEXT_SHMEM 
CACHESTORE_BROKERUSERCERTLOOKUP 
USERSTORE_DBMETADATA 
CACHESTORE_VIEWDEFINITIONS 
MEMORYCLERK_SQLQUERYEXEC 
CACHESTORE_BROKERDSH 
MEMORYCLERK_SQLSOAPSESSIONSTORE 
MEMORYCLERK_SQLQERESERVATIONS 
MEMORYCLERK_HOST 
MEMORYCLERK_SQLXP 
MEMORYCLERK_SQLUTILITIES

 

MTL(Non-BPool)中是什么?

 

COM对象

SQL Server CLR

链接服务器OLEDB提供者分配的内存和在SQL Server进程里第三方DLL的加载

扩展存储过程

网络包

内存管理器消耗的内存。如果内存请求>8KB,并需要持续分配。

 

BUF Structures是什么?

 

SQL Server对每一页维护着一个BUF结构。该结构用于跟踪与每个buffer相关的状态信息,像buffer latch,一个指向实际8KB页的指针,状态位表明该页是否为脏页,有IO处理。

注意,当AWE启用后,BUF structure维护对于整个RAM调整最大服务器内存不用重启SQL Server

 

PAE是什么?

 

PAE用于增加32位处理器寻址多于4GB物理内存的能力。在boot.ini中,启用/PAE使得操作系统利用多于4GB物理内存。

 

什么是SQL Server里的AWE

 

AWE启用,32位的SQL Server将能够使用AWE分配器API寻址多于4GB物理内存。

注意,在32SQL Server里,只有数据页和索引页可以放在AWE内存里。因此,对于其他SQL Server内存对象的可用内存仍然被限制在用户地址空间。

使用AWE分配器API的内存分配不是进程工作集的一部分,因此不能被页交换,在任务管理和perfmonprivate bytes或者working set部分不可见。

SQL Server启动账号需要内存中锁定页面权限来使用AWE分配器API

64位系统里,如果你有AWE分配器API用于分配内存的SQL Server启动账号的内存锁定页面权限,那sp_configure ‘awe enabled’ 没有任何作用。

 

/3GB开关是什么?

 

/3GB开关用于Boot.ini文件。

当我们启用/3GBSQL Server的用户地址空间或者任何使用IMAGE_FILE_LARGE_ADDRESS_AWARE的应用程序将会增加到3GB,而限制内核模式地址空间为1GB

当系统中的物理内存超过16GB,并且使用/3GB开关,操作系统将会忽略额外的内存,直到/3GB开关被移除。这是因为内核增加的大小需要支持更多页面表条目(Page table Entries)。

 

AWE如何工作?AWE分配器API是什么?

 

AWE API**程序寻址多于通过标准32位寻址的4GB内存。

 

AWE API如何使用?

 

匹配AWE页面分配地址空间。

ADD=VirtualAlloc(lpaddress,size,MEM_RESERVE |MEM_PHYSICAL,PAGE_READWRITE);

分配不能被页交换的物理内存。

bResult=AllocateUserPhysicalPages(GetCurrentProcess(),&sizemap,aRAMPages);

匹配一个到你地址空间的页面视图。

bResult=MapUserPhysicalPages(ADD,sizemap,aRAMPages);

 

2.    64SQL Server内存架构

 

64Windows里,每个进程获得高达8TB的地址空间,因此SQL Server不需要预留一定的内存地址空间用于Non-Bpool分配。

 

64SQL Server里有三种内存模型:

  1. Conventional – 普通物理页面大小(4/8KB),内存可以页交换,动态的

  2. Locked – 普通物理页面大小(4/8KB),Bpool不能被页交换,动态的,需要SQLServer启动账号有内存中锁定页面权限,内存通过使用AWE API分配

  3. Large – 大物理页面大小(>=2MB),不可页交换,静态,在启动时内存确定,推荐使用“Max server memory”,需要SQL Server启动账号有内存中锁定页面权限和TF834(只在企业版支持,使用>8GB内存)。

 

内存计算在64SQL Server是非常明确的。

SQL Server在启动时计算内存大小并保留它,minimum(reserved space, “Max server memory”)用于Bpool

类似于32SQL Server,在64SQL Server也有Bpool外的内存分配,被称为Non-Bpool分配。

 

Bpool外谁分配内存?

  1. COM对象

  2. SQL Server CLR

  3. 链接服务器OLEDB提供者和在SQL Server进程里第三方DLL加载的内存分配

  4. 扩展存储过程

  5. 网络包

  6. 通过内存管理器消耗的内存。如果内存请求大于8KB并且需要持续分配。

  7. 备份

  8. 线程的内存(在64SQL Serverstack size2MB

 

最大服务器内存只控制了Bpool,它不控制Non-Bpool分配,这就是为什么SQLServer内存使用大于“Max server memory”的原因。

 

总结:

  1. 当“内存中锁定页面被使用”操作系统不能页交换出Bpool,而Non-Bpool分配仍可以被页交换。

  2. Sp_configure “awe enabled”选项在64SQL Server里没有用。

  3. Max server memory”只限制Bpool,因此SQL Server内存使用将会大于“Max server memory”。

  4. 如果你的操作系统是Windows 2003Windows 2008的话随便你),确保先考虑被其他应用程序、操作系统、驱动、SQL Server Non-Bpool分配等需要的内存,然后设置合适的SQL Server最大服务器内存。

 

注意:以上架构适用于SQL Server2008 R2及以下版本。SQL Server 2012(Denali)与之前版本相比,内存管理器在有效地方式管理SQL Server内存消耗上做出了很多改变。点击这里,了解SQL Server 2012内存架构。

 

内存体系结构(SQL Server2008 R2

https://msdn.microsoft.com/zh-cn/library/ms187499.aspx








本文转自UltraSQL51CTO博客,原文链接:http://blog.51cto.com/ultrasql/1789618 ,如需转载请自行联系原作者