解决SQL Server虚拟内存不足情况

2020-03-01 作者:计算机教程   |   浏览(187)

解决SQLServer虚拟内存不足情况 症状 在具有2GB或更多RAM的计算机上,除了256MB(SQLServer7.0)或384MB(SQLServer2000)虚拟地址空间之外,SQLServer在启动过程中保留剩下的所有虚拟地址空间以供缓冲池使用。另外,为了存储数据和过程缓存,SQLServer使用缓冲池内存为来自SQLServer进程的大多数小于8KB的其他内存请求提供服务。剩下的未保留内存准备用于不能从缓冲池得到服务的其他分配。这些分配包括、但不限于以下各项:SQLServer创建的所有线程的堆栈和关联的线程环境块。在SQLServer创建了所有255个工作线程之后,这大约为140MB。 由在SQLServer地址空间(根据具体系统而有所不同)中运行的其他DLL或进程进行的分配,如:任何链接的服务器中的OLEDB提供程序。 通过使用sp_OA系统存储过程或扩展存储过程加载的COM对象。 加载到地址空间中的任何映像(.exe或.dll),这些映像通常使用20到25MB,但是如果您使用链接的服务器、sp_OA或扩展存储过程,则这些映像可能使用更多的空间。 进程堆和SQLServer可能创建的任何其他堆。在启动过程中,此空间通常为10MB,但是如果您使用链接的服务器、sp_OA或扩展存储过程,则此空间可能更多。 来自SQLServer进程的大于8KB的分配,例如较大查询计划、网络数据包大小配置选项接近于8KB时发送和接收缓冲区等情况所需要的分配。要查看此数字,请查找在DBCCMEMORYSTATUS中报告的OSReserved值,该值是作为8KB页的数目报告的。通常,该值为5MB。 跟踪缓冲池中每个缓冲区状态信息的数组。该值通常约为20MB,除非SQLServer运行时启用了地址窗口化扩展插件(AWE),在这种情况下,该值将会显著提高。 在拥有大量数据库的系统上,日志格式化所需的64KB分配可能会占用所有剩余的虚拟内存。这之后的分配将失败,导致本文的“症状”一节中列出的一个或多个错误。 通过使用-g启动参数,您可以指示SQLServer保留附加的虚拟内存可用,以便这些与日志相关的分配和其他正常分配加在一起也不会用完虚拟地址空间。 下表根据数据库的数目和服务器版本列出-g值的一些建议初始值:DatabasesSQLServer7.0SQLServer2000 250-g134N/A 500-g185N/A 750-g237N/A 1000-g288-g288 1250-g340-g340 1500-g392-g392 此表是使用列出的典型值进行计算的,并且此计算是基于没有使用链接的服务器活动、sp_OA或扩展存储过程这一假设的。它还假设您没有使用AWE和SQL事件探查器。出现以上任意一种情况都需要您增加-g的值。 如果服务器上数据库的数目超过此数目,Microsoft建议您在运行该服务器之前进行慎重的考虑,因为系统上具有如此数目的数据库所需的系统开销将占用缓冲池中的大量虚拟内存,从而可能导致系统整体性能下降。 :打造SQLServer2000的安全策略

误区二:在开启了AWE后,SQL Server的所有功能一定能使用超过2G的内存。

在SQL server进程中,内存并非全部由SQL server的数据缓存所使用,部分通过SQL server调用的第三方代码、加载在SQL server内部的其他dll、SQL server连接、链接服务器、编译缓存、查询计划缓存等也会使用SQL server进程中的内存。

这部分组件或者功能在申请内存时与传统的数据缓存申请的方式不同,因为他们通常会申请大于8KB的内存页,这种内存区域为multi-page(以前叫memtoleave)。对于multi-page占用的内存,是没法使用SQL Server的AWE特性的,也就是说,在32位的SQL Server中,数据库即使开启了AWE,也只能使用到2G的内存(用户态)。由此可见,AWE更多的是提升了data page buffer pool的内存空间。

备注:在32位的SQL Server中,multi-page的默认大小为256MB sp_configure配置的最大线程数X512KB,它是SQL server启动时就已经设定好的。

备注:在64位的SQL server中,multi-page的大小没有限制。

 

www.2003.com,误区八:如果其他应用程序也需要内存,SQL server会释放一部分自己的内存,以保证其他应用程序能够正常运行。

SQL Server不会为其他程序释放自己以占用的内存,只有在操作系统遇到内存压力时,才会根据操作系统的要求减少自己的内存占用量。

但如果SQL server启用了锁定内存页的,那即使是操作系统有要求,其内存也不会释放。因为锁定内存页会使SQL server占用的内存长久保留在物理内存中,避免被分页到虚拟内存中去,这是提升SQL server性能的常见做法。在SQL Server的推荐配置中,我们经常建议客户这样做。不够为了避免内存占用太大,可以通过设置最大内存来限定内存的使用上限。

 

内存对数据库而言是如此的重要,因此只要在涉及数据库优化的地方,我们都可以看到内存的身影。我们通常会想尽各种办法来优化数据库内存的使用,比如开启AWE、设置最大内存、锁定内存页等,但在很多时候,我们实际上都不知道某个配置是否一定能够解决当前的问题,或者我们误以为会解决当前的问题,出现这种现象的原因是我们对数据库的内存理解还不够透彻或者理解存在误区,本文我希望将结合自己的经验和《SQL Server 2012实施与管理实战指南》的内容,通过以【介绍SQL server常见内存误区】的方式跟大家分享下我对SQL server内存的理解。

误区七:增加内存一定能够提升SQL server的性能。

数据库虽然会尽可能多的占用内存,但并不意味增加内存就一定是越多越好,就如同上文说的,如果数据库的内存长期没有什么压力,增加内存也不会带来性能的提升。

另外,在32位 的SQL server中,在数据库启动时就为连接、查询计划、第三方dll、链接服务器等分配了固定大小的multi-page(上文在介绍AWE时已有介绍),因为multi-page的大小不会随着内存的增加而改变,所以即使增加内存,也无益于这些功能、组件,而只是为增大了数据缓存。

备注:在64位的SQL server中,multi-page的大小没有限制。

 

误区三:SQL Server进程不会使用超过最大内存设置的内存大小。

在SQL server的sp_configure中有一个max server memory (MB)的配置项(SSMS中右击实例,在属性中选择内存也可以看到),我们很多人以为设置了这个值以后SQL server的进程不会使用超过这个大小的内存。

其实不然,max server memory (MB)只是buffer pool的上限。但是在SQL server的内存中,不仅仅包括buffer pool,还有multi-page的内存,对于这部分内存,是无法通过max server memory (MB)来限制的,所以,在实际环境中,我们可能会看到sqlservr.exe这个进程会占用的内存会超过max server memory (MB)设定的值。

备注:一般情况下,multi-page占用的空间不会很大,因此,通常我们将max server memory (MB)约等于SQL server进程占用的内存大小。

 

本文由www.2003.com发布于计算机教程,转载请注明出处:解决SQL Server虚拟内存不足情况

关键词: