SQL Server 内存相关博文

  1. 云栖社区>
  2. 博客>
  3. 正文

SQL Server 内存相关博文

fanr_zh 2013-07-11 16:45:00 浏览479
展开阅读全文

Don’t confuse error 823 and error 832

本文大意:
     错误832:
          A page that should have been constant has changed (expected checksum: 1dcb28a7, actual checksum: 68c626bb, database 13, file 'E:\Program Files\microsoft sql server\MSSQL\data\BlahBlah.mdf', page (1:112644)). This usually indicates a memory failure or other hardware or OS corruption. 
     当一个页从磁盘读入,被标记为干净,如果被修改,变成脏页,检查checksum,发现checksum不再可用,832错误发生,发生这个错误一般出现在:1.内存问题,2.操作系统内存管理器问题,或者流氓程序写入到sql server。
1.通过微软产品支持,跟踪内存
2.通过替换法,替换内存

SQL Server and Large Pages Explained….

本文大意:
windows是支持大数据页的,关于windows大数据页的支持可以看Microsoft windows internal,X64支持2MB的大数据页。
有3个条件决定了是否使用大数据页:
     1.sql server企业版
     2.内存在8G以上
     3.Lock Page in Memory权限
这个检查Lock Page in Memory和buffer pool使用AWE API没有关系,因为Large Page 也是不在work set中,也是不能被page out的。
如果Large Page启用会在error log中有一下信息:
2009-06-04 12: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
但是有人会怀疑,明明没有开启TF 834为什么会用large page,因为TF834只限制buffer pool用不用large page。
开启834之后,buffer pool使用large page,因为large page通过virtualalloc()分配内存,比较慢所以会在开机时一次性分配。
启动时,分配算法:
1.会根据max server memory 和物理内存的最小值,若没有设置max server memory那么会分配所有内存。所以max server memeory的设置很总要
2.当使用large page的时候最让是sql server专用服务器。
3.如果不能分配,那么会分配的少一点,还是不能分配就会报错,服务无法启动。
注意:
     内存size必须是连续的,并且在使用过程中buffer pool 不会自动增长。
     使用large page导致开机时间变成,因为virtualalloc分配内存比较慢,并且时间不单单是分配内存的时间
总结
     1.large page在内存>8gb,并有lock page权限
     2.需要开启TF834,擦能让buffer pool使用large page
   2.需要启动TF834,64操作系统并且已经启动了large page
     3.large page 并不适用所有场景应该测试后再决定

Come on 64bit so we can leave the mem….

本文大意:
     作者在64BIT环境下看到一个错误,并且被问是否和MemToLeave有关。
     作者解释了在64bit下并没有MemToLeave。
当32bit的年代,虚拟地址空间只有4个g,内核2g,用户2g,也可以通过4g选项调整为内核1g,用户3g,反正就是很少,设计者会为buffer pool保留地址,buffer pool有地址了,才不会影响内存的使用。buffer pool尽量大的保留地址空间了,但还是没有用完地址空间,因为有记下几个也需要用内存的:
1.线程stack,2.heap,3.SQL Server多页分配,4.其他DDL分配。
MemToLeave的意思就是留下来用来做别的事情,比如上面的,当服务启动的时候sql server 会先保留一部分地址空间,然后buffer pool保留地址空间,保留完之后,memtoleave释放地址空间。保留的地址的大小如下:线程堆栈大小*线程数+g参数的大小(默认256M)。
当64位来临,带来了大量的地址空间,所以没有必要在再服务启动时去保留地址空间,直接在需要用的时候分配就好了。

TechNet Magazine: October 2009 SQL Q&A column

本文大意:
1.sql server 2005启动的时候发现一致性检查信息,但是不管数据库大小,检查都很快,为什么?
     其实这些并不是实际上的检查,只是把上次最后一次检查的信息输出出来。当dbcc checkdb运行完之后会写入到boot page 上。启动服务的检查只是把boot page的信息print出来。
2.如何确定内存被使用在那个数据库?
     sql server会占用大量内存,并且在没必要的时候是不会释放啊内存,除非os有内存压力。sql server主要的内存都使用在buffer pool中,还有一部分是使用在plan cache中,内存多可以减少io,可以减少编译所占用的时间。可以通过sys.dm_os_buffer_descriptors是buffer pool的信息,来确定是那个数据库占用了内存。当然也可以使用 dbcc memorystatus 来确定实例内存的使用。
3.数据库偶尔会出现SUSPECT和RECOVERY_PENDING的情况,就会需要通过被备份恢复,会有数据丢失的问题,如何解决?
     这2个状态都是由故障恢复的时候出现的,当crash 恢复,读不到日志的时候会出现RECOVERY_PENDING。当日志可读,但是日志可以访问,但是无法完成恢复,一致性不对的时候会出现SUSPECT。有2个原因会导致恢复无法完成,1.日志数据问题,2.数据文件有问题。
还有一个会进入SUSPECT状态就是,当事务回滚,在回滚时出现错误。
可以使用备份来恢复数据,如果没有备份可以转入应急模式,来恢复。
4.高安全的数据库镜像使用witness是如何识别错误的?
     错误识别有一下几种:
     1.sql server实例级crash,每秒ping,能ping通但是发现sql server没有监听端口,立即报告
     2.服务器级别crash,每秒ping 不能ping通马上报告
     3.事务磁盘问题,当日志写入的队列太高,20秒后会写入到error log,40秒后认为log 磁盘offline,触发切换
     4.数据库页出错,数据库会变成suspect状态,马上触发切换
     5.如果文件或者文件组offline,primary正常,当碰到错误是切换。

Performance issues from wasted buffer pool memory

本文大意:
内存浪费是可耻,特别是对于数据库来说,内存不足有一下几个特点:
1.物理io变多,不管读还是写
2.Lazy write变多
3.RESOURCE_SEMAPHORE等待变多,因为查询需要内存
4.大量的plan重编译,因为没有地方放plan cache
 
低数据密度:
     使用sys.dm_os_buffer_descriptors可以看,到底buffer pool 里面有多少是空的,也就是浪费的。
     低数据密度引起的原因一般就怎么几个:
     1.宽行,那么就使用小的数据类型
     2.分页,合理设置填充因子
     3.行删除,导致内部碎片
     低数据密度也会有一下几个代价:
     1.io变多,因为空间被浪费了
     2.磁盘空间被浪费
     3.内存被浪费
 
低数据密度解决办法:
     1.小数据类型
     2.使用顺序的key,不要用随机降低分页
     3.调整填充因子,填充因子本身就是一种浪费,所以要合理不能太大
     4.重建索引
     5.数据压缩
作者各处了一些脚本,自己去原文看,个人觉得还是蛮有用的。

Database mirroring: avoiding ‘cannot obtain a LOCK resource’ problems

本文大意:
在镜像服务器出现不能获取LOCK资源,很有趣,镜像是不会动的,为什么会出现这个错误?
原因很简单,比如一个事务主体回顾的时候,镜像也回滚,会滚就会产生事务,不信自己试试看。
LOCK结构是需要内存的,尽管很小,但是量大的时候,也是很可怕的,作者就认为,主体内存和镜像内存不太一致,导致主体上的lock大量,但是镜像上无法达到这个量导致的问题。那么把2边的内存搞成一样,更有甚者,很多回滚事务同时到镜像,也是会报这个错误,那么就继续加内存。作者的意思是加内存。

Tracking VAS in Yukon

本文大意:
     作者给出了一个sql用来跟踪sql server 对虚拟内存的保存和使用。

A look at Virtual Address Space - VAS

本文大意:
     VAS也就是虚拟地址,一般处理问题的时候很少去关注虚拟地址,虚拟地址使用VirtualAlloc*/VirtualFree*分配和释放,可以保留空间,也可以分配内存。
     分配内存的方式是:先保留空间然后马上分配内存,绑定。VAS最小块为64KB,并以64KB为分配单元。
     每个进程都有VAS,为了方便使用,在VAS分配之后会分配一个VAS,用来描述VAS。VirtualQuery API和sys.dm_virtual_address_dump都是使用VAD查信息。
     VAS是很重要的资源,所以要跟踪这些资源,有2个工具:VASUMP,可以查看VAS利用但是没办法查看是哪个组件分配的。还有一个LEAKDIAG可以跟踪到组件级别的信息。

Tracking VAS in Yukon, cont...

本文大意:
     作者给出了一个跟踪线程stack的例子,来说明。可以使用sys.dm_os_threads,sys.dm_os_load_modules,sys.dm_os_virtual_address_dump连接获取VAS信息
SELECT * FROM sys.dm_os_virtual_address_dump a
       INNER JOIN sys. dm_os_loaded_modules b ON a.region_allocation_base_address = b.base_address
 
SELECT * FROM sys.dm_os_virtual_address_dump a
       INNER JOIN sys. dm_os_threads b ON a.region_allocation_base_address = b .thread_address

A look at Windows Virtual Memory mechanisms (continuation of "A look at Virtual Address Space - VAS")

本文大意:
     VAS绑定page是按需的,当page第一次被访问,绑定发生,一次只能一个页(绑定和提交有什么区别?绑定主要做些什么事情)。若第一次访问出现硬件页错误,那么OS严重VAD,VAS是否提交,若已经提交,OS会在内存中找一个空的页,初始化,并且把页绑定到虚拟地址,并填入数据结构。
     当内存使用紧张,会启动回收机制,把进程中的要释放的页,page 到磁盘上,并修改数据结构,下次访问的时候就会找到,page 完成后,清零并放到free list中。
     错误页,页错误有3种,最被人说道的是2种1:软错误,2.硬错误:
     软错误出现在,第一次访问的时候,因为mmu中没有记录,但是数据页在内存中存在所以会出现。
     硬错误,在内存中不存在在页面文件中有
     物理页能够映射到不同的VAS,若值映射到一个VAS,我们就称私有的,否则就是共享的。使用virtualalloc都不能共享。
     为了不让内存不切换的页面文件,可以使用page lock,page lock会打破系统内内存的平衡,可以使用lock page in memory权限打开。
     4G调整和AWE是对虚拟地址的应用,4G调整,让内核模式只占用1G的内存空间,其他3G为用户模式地址。
     为了能够访问4G以上内存,windows出了一个PAE,物理地址扩展,从32扩展到36能让windows 访问64G物理内存,相应出了AWE,通过virtualalloc分配地址并映射到物理内存的方式访问。AWE的内存os不能page,但是如果滥用,会导致性能问题,只能通过重启进程来释放。

Memory Pressure - Classified

本文大意:
     内存压力分为2种,1.内部压力,2外部压力
     外部内存压力又分为,静态内存压力:系统运行超出页面文件,导致系统内存不足,动态内存压力:os可用内存不足。
     windows会通知进程当前内存是否有压力,或者你内存太多,应用程序实施的开辟内存或者收缩内存。
     内部内存压力分为:1.内存压力,2.VAS压力。
     外部内存压力导致内存收缩就可能英气内部内存压力。或者使用内存的限制也可能导致内存压力。处理方法:收缩stack,pool,把内存返回给内存管理器
     造成VAS压力的情况2中:1.VAS碎片导致,无法开辟联系的VAS空间,2.VAS地址空间不够消耗的。VAS不足会导致,系统变慢,甚至进程终止。处理方法:收缩stack,pool。
     以下几点要在实现,内存通知的时候注意:
     外部内存压力出现:内存被page out,内存压力通知,释放内存,内存变多,有开辟,又有内存压力通知以此循环
     当页面文件变小,没有通知,而是在下次分配的时候直接报out of memory

SQLOS's memory manager and SQL Server's Buffer Pool

本文大意:
内存节点:主要提供本地内存的分配,由一些分配器组成。
内存clerk:clerk有4中类型,generic,cache store,user store,object store,可以用来跟踪内存的使用。
内存对象:内存对象的内存分配会被记录到clerk中。对象分为3种:1.可变内存对象常规heap,2.自增内存对象,是mark/shrink heap 3.固定长度的内存对象(内存对象内部还没有研究),内存对象和clerk都有页分配器地址,可以使用这个,查看对象对应的clerk。
buffer pool:sp_configure,有2个参数,最大服务内存,最小服务内存,用来控制buffer pool,但是不能控制其他组件。在服务启动的时候,sql server 会先保留一部分地址空间,是g参数+最大线程数*512KB(32位,64位为2M)就是MemtoLeave。然后再为buffer pool保留地址空间。buffer pool是根据内部内存和外部内存状况按需分配,计算目标内存,根据实际状况计算,并不引起内存压力,为了避免page,target经常被重新计算。buffer pool分配单元大小是8kb,其他组件需要内存时可以用buffer pool作为底层内存管理。在sql server 启动的时候buffer pool被设置为sqlos的单页分配器。对于大的组件都有自己的clerk,buffer pool也一样通过VM/AWE/SM分配内存。所有组件从buffer pool分配内存最好,所以小内存分配首选buffer pool,当需要大内存的时候从Mutil Page等分配。
buffer pool和AWE机制:有几个注意点:1.buffer pool通过clerk来记录VAS和物理页的分配,2.buffer pool使用4mb的VAS而不是大的,因为4MB容易对内存压力做出反应。3.2000中BP是一次性分配的,2005则是按需分配的。AWE不算workset,所以当启动AWE是,内存分配很难在里面发现。只有buffer pool能够map,unmap内存,所以其他组件不能使用AWE。

SQLOS's memory manager: responding to memory pressure

本文大意:
     内存压力实际上可以分为VAS,物理内存,物理内存压力可能是外部压力,也可能是内部压力。
     RM运行一些监控的指标,来判断是否有内存压力。一旦有问题就会广播到memory clerk。RM位于cpu节点上,所以可能有多个RM在运行。
     多数内存的消耗,在clerk中都有记录,而且每个cpu节点都有一份clerk,RM先计算通知,然后通过list广播通知。
     有几个注意点:1、RM有自己的调度器,2.RM运行在非抢占模式下,3.DAC节点没有RM
     外部内存压力,RM,Buffer pool:BP被当做一个单页分配器,当出现外部内存压力,RM广播到clerk,BP重新计算可用内存,然后shrink,一直循环知道压力消失。但是不低于最小服务内存。
     内部内存压力,RM,Buffer Pool:当buffer pool出现内存压力,sqlos通过一些机制打开RM内部内存压力的标识符,然后通知clerk,buffer pool并不对内部内存压力作出反应。动态修改最大服务内存,BP中75%的页被steal也会触发内部内存压力
     VAS压力:当virtual或者shared memory分配4MB的地址空间失败,或者扫描VAS不存在4MB的连续空间时,通知VAS不足。2000中很难对VAS压力处理,在2005中会通知所有的clerk所有会有机会去shrink:1.shrink thread,2.卸载CLR,3.network lib收缩buffers。当buffer pool使用AWE时,发现有4MB的地址空间没有被使用的,也会被释放。
     通过查看DMV:
SELECT      *
FROM  sys .dm_os_ring_buffers
WHERE ring_buffer_type = 'RING_BUFFER_RESOURCE_MONITOR'     
随着时间,就很容易看出尽力了哪些内存压力。

SQLOS Caching

本文大意:
     2000中,cache主要是2种:data page cache:buffer pool,procedure cache:plan cache,plan cache通过buffer pool来完成对cache大小的控制,但是随着2005,cache变得越来越多,所以通过buffer pool控制是不太可以理解的,所以使用了通用的框架。
     2005中有3总主要的cache 类型:cache store,user store,object store,其中又分为cache 和pool,其中 cache strore 和user store是cache,object cache 是pool
     cache最主要的特点是:存放各种不同的数据,使用cost,结合lru来实现算法。pool:没有cost,也不需要做lru算法。并且有2个概念:生命周期控制,和可见性控制
     生命周期的算法可以自己实现,也可以用框架的,比如cache store 是使用框架的,user store是自己一部分,框架一部分。生命周期通过应用计数管理,
     可见性通过pin count管理
     SQLOS 通过LRU算法实现了可见性和生命周期的控制,模拟LRU算法实现了时钟策略,外部时钟指针,和内部时钟指针。
     外部时钟指针:通过RM而移动用来控制sql server 整体内存
     内部时钟指针:用来控制cache 的大小,避免单个cache占用过大的内存。
     时钟指针移动并不会影响存储,并且只有当2个指针都运行过的时候,内存块才会被回收。

 

Be Aware: Using AWE, locked pages in memory, on 64 bit
本文大意:
     64位中还是可以使用AWE的,AWE使用的步骤2步:1.分配内存(PFN),2.映射到VAS中。但是AWE分配的内存释放1.终止进程,2.程序控制释放。
     通过页表项(PTE)来表示用来描述物理内存和VAS的映射,内部物理也通过PFN表示。OS有个库用来保存PFN,AWE分配后的PFN也保存在这里,一旦屋里也绑定到VAS,PFN会指回PTE。AWE分配的内存一旦与VAS绑定就是lock的不会被换出。
     在64位下使用AWE有2个好处:1.不会被换出,对于NUMA有显示的驻留信息,当被page后很难再回到,原来的处理器,这样做显然会增加访问内存的消耗。2.锁定是workset和PFN锁定。这样可以让应用程序运行的较快,并且扩展性也较好。numa中buffer pool通过queryworkingsetex函数来查询内存所在的节点信息,因为是lock的所以只需要执行一次即可,提高了性能。唯一要注意的是内存不足时,lock的内存没办法被换出,获取可能内存。

Q and A: Controlling size of a single cache in SQL 2005

本文大意:
     Q:plan cache太大,会不会造成查找plan的瓶颈,如何控制cache大小?
     A:内部指针用来控制内部单个cache的大小,以免出现性能问题,当框架预测过程最大cache到达了就会移动内部指针。还有当有一些项进入cache,具体多少项根据最大服务内存来确定,还有就是机器上的内存状态。

SQL Server 2005 NUMA support & troubleshooting

本文大意:
     NUMA有2中方式,1:纯NUMA,2:交错是NUMA。NUMA是每个节点都有自己管理的内存,本地访问代价比远程访问代价小。交错numa是当成SMP访问,适合对NUMA没有优化的程序。
     当配置成纯NUMA然后重启,windows就会识别,通过观察发现大多数内存都是开辟在第一个节点上,开辟的数量和可用内存数量,要启动的进程有关。这样的开辟方式会让内存出现不均衡的状况。
     
     SQL Server Node有自己的内存管理和调度个数,io和其他组件,node的在线和离线通过affinity设置。在没有显示规定指定那个节点是,是通过环形的方式分配。
 
     在SQL变慢,但是plan没有变化,造成性能下降,往往可能是内存的问题引起:
     1.Node 0,系统启动过程中都是使用node 0的内存,方法是把node 0 offline
     2.其他node,查看SFC,其他进程内存的内存消耗,和SQL Server的内存消耗。方法:在启动其他进程前,为sql server通过设置min,max一样来保留内存。
     3.错误的配置SFC,导致内存的大量消耗。

Final changes in SQL Server 2005's memory manager

本文大意:
Memory Broker:用来调整buffer pool,query execution,query优化,cache之间的内存分配,让内存更有效的使用。根据组件的内存需求调整内存分配,计算最优分配方案,然后广播到clerk。
SELECT       *
FROM   sys . dm_os_ring_buffer
WHERE  ring_buffer_type = 'RING_BUFFER_MEMORY_BROKER'
NUMA:SQL Server 当本地无法分配内存的时候会从其他有内存的节点分配内存。每个节点内存分配为max/Nodes 如果设置了affinity那么就是 max/affinity Nodes

 

Q and A: Virtual Address Space, VAS, reservation - why bother?
本文大意:
Q1:经常提到保留但是没有提交是讲的是VAS吗?
A1:是讲的是VAS,如当查询执行需要内存,那么就会去buffer pool里面保留内存,这个和VAS的保留和提交时2回事。
 
Q2:为什么不在保留的时候直接提交内存,而是需要先保留然后再提交
A2:先保留的理由有2个1:因为有很多的提交方式,如:AWE,file map等。2:VAS有限,以免发生不必要的争用。
 
Q3:保留的VAS能收缩或者增长吗?
A3:一旦被保留就不能grow,收缩,只能一起释放。
 
Q4:当VAS保留了,但是分配不到内存会发生什么情侣:
A4:造成这个往往是内存不足引起,会记录在错误日志上面,ring_buffer也会有一些错误,会有OOM通知。

Q and A: Clock Hands - what are they for?

本文大意:
Q1:时钟指针到底是干嘛用的?和lazywrite有关系吗?
A1:2005把cache分为2部分,BP和其他cache,lazywrite还是会控制数据页的内存消耗。在2005中引入了通用的cache框架,除了buffer pool之外都会使用这个,这个框架是由RM和一系列store组成,有3中store:cache,user,object。cache,user使用通用的基于cost的LRU算法,object只是一个pool不需要LRU算法和Cost。时钟指针所过之处,cost减半,当cost变0,就可以销毁了,当要重用的时候重新设置cost。指针分为2中:1.全局(外部),以全局内存做LRU算法。2.本地(内部):以本组件内存做LRU算法。尽管每个cache都有外部,但是都是同时运行的,就是为了模拟全局指针。RM通过通知内存压力来驱动外部指针。内部指针在cache需要被裁剪的时候运行,保证cache的内存占用的合理大小。

Q and A: SQL Server memory allocated outside of Buffer Pool, formerly known as MemToLeave

本文大意:
Q1:在sql server2000的MemToLeave的概念是否在64Bit下是否继续可用?
A1:是的,当组件需求大于8kb的时候还是会从MemToleave中分配。
 
Q2:大于8KB在MEMToLeave分配,那么在64位下还是如此吗?
A2:还是一样的8KB一样的会从MemToLeave分配,但是有的时候如果数据结构过大的,也会直接从MemToLeave分配

Q & A: Does SQL Server always respond to memory pressure?

本文大意:
Q: 在我的2005中,开启了Page Lock碰到了一个问题,我怀疑是内存都没2005占用没有释放,倒是可用内存不足,导致服务器僵死。如何能和2000一样当出现内存压力的时候可以释放呢?
A: 在2005中不管是不是Page lock都会对内存压力做出反应。没有释放内存可能是没有cpu时钟去运行释放的问题造成。对于page lock的要设置max server memory,有几个max server memory的建议配置:
< 4GB                   512MB - 1GB
4-32GB                 1GB - 2GB
32GB - 128GB       2GB-4GB
128GB -                4GB-
有记下几点要注意:
1.当服务器运行在内存的边界,需要设置max server memroy
2.在高峰期的时候,注意,你的max server memory是否设置在一个合理的值中
3.内存越多max的设置越重要
4.通过测试,或者基线寻址自己的max server memory
5.max worker thread,stacj 在32为512KB,在64为2MB,在IA64中为4mb,所以设置的时候注意是否会引起内存问题
6.max server memory 只对BP起作用,对其他组件没有作用
7.对于外部组件,如xps,com的内存分配不受max server memory控制

网友评论

登录后评论
0/500
评论
fanr_zh
+ 关注