SQL Server 2014里的缓存池扩展

在今天的文章里我想谈下SQL Server 2014里引入的缓存池扩展(Buffer Pool Extensions)。我们都知道,在SQL Server里,缓存池是主要的内存消耗者。当你从你存储里读取数据时,数据会在缓存池里缓存。SQL Server在计划缓存里缓存执行计划,也是缓存池的一部分。你拥有的物理内存越多,你的缓存池就会越大(通过【最大服务器内存】设置配置)。

很多SQL Server用户会碰到数据库服务器里物理内存受限的问题:所有内存槽都被占用了,因此你如何想给物理服务器增加额外的内存?当然,你可以迁移到更大的服务器,但那是另外一回事……这个特定问题的解决方案是SQL Server 2014里引入的缓存池扩展。在缓存池扩展的帮助下,SQL Server在内存层级里引入了另外一层。我们来看下面的图片:

如你所见,在顶部是缓存池本身,它是非常快的(根据响应时间(latency times)),在底部你会看到我们的传统存储,它是比较慢的。缓存池扩展刚好落户在2者之间——传统缓存池和我们存储之间。缓存池苦熬占本身是包含一个简单文件(所谓的扩展文件(Extension File)),它应该存储在非常快的存储上——例如SSD硬盘。扩展文件大体上和Windows系统的页文件一样。不用在你的数据库服务器增加额外的物理内存,你只要配置在SSD硬盘上配置扩展——就可以了!

在我讨论配置并启用缓存池扩展前,我想简单谈下缓存池扩展的架构和背后的设计。SQL Server传统的缓存池总是在干净页和脏页间区分的。干净页就是内存里的内容和存储里的内容一样的页。脏页是在内存里改变的页,但还没有写回到存储。大约每分钟所谓的检查点(CHECKPOINT)过程会把脏页写回到存储,意味着脏页变成了干净页。

如果SQL Server的缓存池陷入内存压力,缓存池扩展本身就会被使用。内存压力指的是SQL Server需要比当前可用更多的内存。在那个情况下,缓存会从缓存池驱逐页,那些页是最近刚使用过的。SQL Server这里使用的是近期最少使用算法(Least Recently Used Policy (LRU))。如果现在你配置了扩展文件,SQL Server会把这些页写到扩展文件,而不是把它们直接写入我们缓慢的存储。如果页是脏的,这些页也会并发写入物理存储(通过异步I/O操作)。因此当你使用缓存池扩展时,你不会丢失任何数据。到一定时间点你的扩展文件也会完全存满。在那个情况下SQL Server又会从扩展文件驱逐老页(也是通过LRU算法),最后把它们写入传统存储。扩展文件充当缓存池和存储本身之间的额外一层。

现在我们来看下在SQL Server 2014里如何配置缓存池扩展。SQL Server这里提供你ALTER SERVER CONFIGURATION SET BUFFER POOL EXTENSION命令。我们来详细看下如何使用它:

1 USE master
2 GO
3
4 EXEC sp_configure ‘show advanced options‘, 1
5 RECONFIGURE WITH OVERRIDE
6 GO
1 ALTER SERVER CONFIGURATION
2 SET BUFFER POOL EXTENSION ON
3 (
4    FILENAME = ‘d:\ExtensionFile.BPE‘,
5    SIZE = 1 GB
6 )
7 GO

这里你会碰到的第1个限制是扩展文件必须和缓存池本身一样的大小,如果你指定了比它小的文件大小,你会从SQL Server收到如下的错误信息:

Msg 868, Level 16, State 1, Line 1
Buffer pool extension size must be larger than the current memory allocation threshold 1596 MB. Buffer pool extension is not enabled.

下一个你肯定会碰到的限制是,在SQL Server运行期间,你不能修改扩展文件的大小。例如,当你想修改扩展文件到更大的大小,你需要停用缓存池扩展,然后再次启用。在此操作期间,你的性能会下降,因为你刚刚停用了SQL Server一个重要的缓存层!

当你计划为你的生产环境部署缓存池扩展时,你一定要意识到这点!!!

另外你不能缩小扩展文件的大小,文件必须要比先前的大。不然你还会收到如下的错误信息:

Msg 868, Level 16, State 1, Line 3
Buffer pool extension size must be larger than the current memory allocation threshold 4096 MB. Buffer pool extension is not enabled.

缓存池扩展的整个配置也可以通过DMV sys.dm_os_buffer_pool_extension_configuration来查询到。

什么时候你应该使用缓存池扩展?微软建议在你的服务器工作负荷是少读多写(write-heavy)时,例如OLTP工作负荷。当你处理DWH/BI相关的工作复核时,你不应该考虑缓存池扩展——这里启用扩展文件没任何意义。并且当我们讨论扩展文件时,你应该为它配置好非常快的SSD!传统旋转硬盘(机械硬盘)就算了吧!

时间: 2024-10-08 20:50:21

SQL Server 2014里的缓存池扩展的相关文章

SQL Server 2014里的性能提升

在这篇文章里我想小结下SQL Server 2014引入各种惊艳性能提升!! 缓存池扩展(Buffer Pool Extensions) 缓存池扩展的想法非常简单:把页文件存储在非常快的存储上,例如SSD硬盘,用来扩展缓存池.缓存池扩展来得非常方便,如果你不能给你的数据库服务器物理上增加更多的内存,可以考虑使用缓存池扩展. 资源调控器(Resource Governor) 资源调控器首次是在SQL Server 2008里引入的,但那个时候还不是个成熟的技术,因为你不能在存储级别调控I/O操作,

SQL Server 2014新特性——Buffer Pool扩展

Buffer Pool扩展 Buffer Pool扩展是buffer pool 和非易失的SSD硬盘做连接.以SSD硬盘的特点来提高随机读性能. 缓冲池扩展优点 SQL Server读以随机读为主,SQL Server IO分为2部分:buffer pool管理方式,和buffer pool. SQL Server 从磁盘中读入数据,并且存放在buffer pool中以供读取和修改,修改完之后脏数据还是放在buffer pool中,当内存紧张执行lazy write把脏数据写入磁盘,并且释放内存

在SQL Server 2014里,如何用资源调控器压制你的存储?

在今天的文章里,我想谈下SQL Server 2014里非常酷的提升:现在你终于可以根据需要的IOPS来压制查询!资源调控器(Resource Governor)自SQL Server 2008起引入,但提供的功能还是有所限制:你只能限制CPU时间(这个已经很棒了),还有你能限制查询(从每个独立的查询)内存量. 但作为DBA的你,你经常会进行一些数据库维护操作,例如索引重建,DBCC CHECKDB操作等.我们都知道,这些操作会在你的存储里带来大量的IOPS直至峰值.如果在7 * 24在线的数据

SQL Server 2014里的针对基数估计的新设计(New Design for Cardinality Estimation)

对于SQL Server数据库来说,性能一直是一个绕不开的话题.而当我们去分析和研究性能问题时,执行计划又是一个我们一直关注的重点之一. 我们知道,在进行编译时,SQL Server会根据当前的数据库里的统计信息,在一定的时间内,结合本机资源,挑选一个当前最佳的执行计划去执行该语句. 那么数据库分析引擎如何使用这些统计信息的呢?数据库引擎会根据数据库里的统计信息,去计算每次操作大约返回多少行.这个动作称之为基数计算(cardinality estimation).数据库分析引擎会基于这些信息判断

在SQL Server 2014里可更新的列存储索引 (Updateable Column Store Indexes)

传统的关系数据库服务引擎往往并不是对超大量数据进行分析计算的最佳平台,为此,SQL Server中开发了分析服务引擎去对大笔数据进行分析计算.当然,对于数据的存放平台SQL Server数据库引擎而言,也是需要强大的数据处理能力的. 在SQL Server 2012时,SQL Server 引入了列存储索引,用以显著提供高传统数据仓库类型语句的性能,并在SQL Server 2014中做了进一步加强.本文将在对SQL Server 2012列存储索引简单介绍的基础上,进一步解释SQL Serve

SQL Server 2014里的IO资源调控器

在本文中,我们将来看看SQL Server 2014在资源调控器方面增加了哪些新的功能.资源调控器(Resource Governor)是从SQL Server 2008开始出现的一项功能.它是用于管理 SQL Server 工作负荷和系统资源使用情况的功能. 在SQL Server 2014之前,资源调控器只能限制某些用户访问SQL Server所占用的CPU带宽.内存资源.但是随着虚拟化和云技术的发展,IO的控制有了很大的需求.IaaS(Infrastructure as a Service

第16/24周 SQL Server 2014中的基数计算

大家好,欢迎回到性能调优培训.上个星期我们讨论在SQL Server里基数计算过程里的一些问题.今天我们继续详细谈下,SQL Server 2014里引入的新基数计算. 新基数计算 SQL Server 2014里一个增强是新的基数计算.上个星期你已经学到老基数计算有些限制,会生成错误的估计,这会导致不好的执行计划表现.截至SQL Server 2012,你一直在使用自SQL Server 7.0引入的基数计算. 当然,几年来也有很多问题被修正,但默认它们都没启用的——你需要启用SQL Serv

SQL Server 2014如何提升非在线的在线操作

在今天的文章里,我想谈下在线索引重建操作( Online Index Rebuild operations),它们在SQL Server 2014里有怎样的提升.我们都知道,自SQL Server 2005开始引入了在线索引重建操作.但这些在线操作并非真正的在线操作,因为在操作开始时,SQL Server需要获得共享表锁(Shared Table Lock (S) ),在操作结束时需要在对应表上获得架构修改锁(Schema Modification Lock (Sch-M) ).因此这些操作是真

SQL Server 2014,表变量上的非聚集索引

从Paul White的推特上看到,在SQL Server 2014里,对于表变量(Table Variables),它是支持非唯一聚集索引(Non-Unique Clustered Indexes)和非聚集索引(Non-Clustered Indexes)的.看到这个,我决定在自己的虚拟机里尝试下,因为这将是个卓越的功能.表变量很棒,因为用它可以避免过多的重编译(excessive recompilations).当你创建它们时,它们是没有统计信息,你不会改变数据库架构.它们只是变量,但在Te