SQL Server 数据页缓冲区的内存瓶颈分析

SQL Server会把经常使用到的数据缓存在内存里(就是数据页缓存),用以提高数据访问速度。因为磁盘访问速度远远低于内存,所以减少磁盘访问量同样是数据库优化的重要方面。

当数据页缓存区出现内存不足,则会出现查询慢,磁盘忙等等问题。

分析方法:主要是用到性能计数器。

查看如下性能计数器:

1. SQL SERVER:Buffer Manager-Lazy Writes/sec:内存不足则会频繁调用Lazy Writer把数数据写入磁盘,此值会经常不为0.

2. SQL SERVER:Buffer Manager-Page life expectancy:内存不足时,此计数器表现为下降趋势或者一直停留在较低值。

3. SQL SERVER:Buffer Manager-Page reads/sec:内存不足时,则查询那些经常使用但又没有缓存在内存里的数据时,就不需要读取磁盘,这此值表现为持续上升或者停留在较高值。

4. SQL SERVER:Buffer Manager-Stolen pages:Stolen pages通常用于缓存执行计划,以备重用。内存不足时,SQL Server本身机制会优先清除执行计划缓存,则此值表现为下降或者较低水平。

查询当前用户任务等待:

代码如下:

select * from sys.sysprocesses

如果内存不足则,会看到较多的ASYNC_IO_COMPLETION等待类型。这是因为内存不足时:a.内存和磁盘间会频繁进行交互,磁盘负载增加 b.需要读取磁盘上的数据完成查询,磁盘负载增加。

也就是说这时候磁盘也出现了性能瓶颈,但是这只是“表面”的,我们要结合多个性能指标来认清根本原因是“内存不足”。

确定压力来源及解决办法:

通过前的分析,确定了数据页缓存相关的内存瓶颈。就要分析为什么会这样及解决办法。主要分为如下5个方面:

1. 外部压力

如果OS层面或者其它应用服务需要更多的内存,windows会压缩Database Pages的内存量。这时内存压力来自外部。可以查看如下性能计数器确定是否是外部压力:

1. SQL Server:Memory Manager-Total Server Memory:此计数器值会下降。

2. Memory:Available Mbytes:此值会下降到较低水平。

3. 在没有使用AWE或者Lock page in memory前提下,查看Process:Private Bytes-SqlServer和Process:Working Set-SqlServer,两者值会有显著下降。

解决方法:如果非DB专用服务器,则要权衡各个应用服务之间重要性来分配内存或者加大内存。尽量让服务器只运行SQL Server,成为DB专用服务器。

2. SQL Server自身对Database Page的使用压力

当Total Server Memory已经达到设定的Max Server Memory或者无法从OS获得更多内存,但是经常访问的数据量又远大于物理内存用于数据缓存的容量时,SQL Server被迫将内存的数据移入又移出,用于完成当前查询。

观察如下性能计数器:

1. SQL Server:Memory Manager-Total Server Memory 和 SQL Server:Memory Manager-Target Server Memory两者值将会相等。但是前者不会大于后者。

2. 将会出现“分析方法”所述之情况。

解决方法:既然SQL Server没有足够内存存放Database Page,那就要么增加SQL Server使用的内存量或者减少其使用的内存里。

增加:可以通增加物理内存,启用AWE等方法。

减少:可以通过横向扩展,有两台或者多台服务器分别载部分库;优化相关读取量较大的语句等。

3. Buffer Pool中的Stolen Memory压力

正常情况下Buffer Pool中的Stolen Memory不会给Database Pages造成压力。因为Database Pages有压力,会触发Lazy Writes,同时SQL Server 会清理Stolen Memory中的执行计划缓存。

但是,如果用户申明了过多的对象,而没有登出,并且占用内存过多,就会压缩Database Pages.如:游标,自定义引用的执行计划等。

解决方法:通常是会表现为a)用户提交的请求因内存不足无法完成,701错误;b)需要压缩某些clerk的内存量,来完成用户请求,造成响应延时和缓慢。

通过查询sys.dm_os_memory_clerks的字段Single_pages_kb,找出是哪个clerk使用了过多内存并分析其原因,然后解决之。

4. Multi-Page的压力

multi-page跟Buffer Pool共享OS的虚拟地址空间,如果multi-page使用过多内存,就会压缩Datbase pages。multi-page内存用量一般较小且相对固定,可能发生的情况有:

a. 未开启AWE的32位SQL Server只有2G地址空间,且用-g启动参数扩展的MemToLeave的上限。

b. 64位SQL Server调了内存泄露的第三方代码。

c. 使用带有大量参数或者较长的”IN”语句

d. 调高了Network Packet Size,大于或等于8KB,并且较多这种连接。

e. 大量复杂XML查询,或者第三代码。

解决方法: 通过查询sys.dm_os_memory_clerks的字段multi_pages_kb,找出是哪个clerk使用了过多内存并分析其原因,然后解决之。

作者:Joe.TJ

(0)

相关推荐

  • SQL Server 数据页缓冲区的内存瓶颈分析

    SQL Server会把经常使用到的数据缓存在内存里(就是数据页缓存),用以提高数据访问速度.因为磁盘访问速度远远低于内存,所以减少磁盘访问量同样是数据库优化的重要方面. 当数据页缓存区出现内存不足,则会出现查询慢,磁盘忙等等问题. 分析方法:主要是用到性能计数器. 查看如下性能计数器: 1. SQL SERVER:Buffer Manager-Lazy Writes/sec:内存不足则会频繁调用Lazy Writer把数数据写入磁盘,此值会经常不为0. 2. SQL SERVER:Buffer

  • SQL Server数据表压缩

    概述 SQL Server的主要性能取决于磁盘I/O效率,SQL Server .2008提供了数据压缩功能来提高磁盘I/O效率.表压缩意味着减小数据的磁盘占有量,所以压缩可以用在堆表.聚集索引的表.非聚集索引的表.索引视图.分区表上. 可压缩的数据类型 smallint.int.Bigint.decimal.numeric.real.float.money.smallmoeny.bit.datetime.datetime2.datetimeoffset.char.nchar.binary.ro

  • SQL Server数据迁移至PostgreSQL出错的解释以及解决方案

    问题重现: 1.PG客户端: postgres=# create table text_test (id int,info text); CREATE TABLE postgres=# insert into text_test values (1,E'\0x00'); ERROR: invalid byte sequence for encoding "UTF8": 0x00 2.SQL Server产生数据 create table test_varchar(id int,name

  • SQL Server数据复制到的Access两步走

    我们今天主要向大家讲述的是把SQL Server数据复制到的Access数据库中的实际操作步骤,把SQL Server数据库中的某些数据复制到的Access数据库中,其表的主要结构是相同的,不要提用openrowset,因为Access文件和SQL Server不在一台机器上. 初步的想法是用两个recordset,一个从SQL取数据,一个往Access里面插入数据 因为表的字段比较多,所以只好用一个循环 while (!m_pRecordset_sql->adoEOF) { m_pRecord

  • SQL Server数据表字段自定义自增数据格式的方法

    本文实例讲述了SQL Server数据表字段自定义自增数据格式的方法.分享给大家供大家参考,具体如下: --修改数据表SYS_Company中字段CompanyId自定义自增约束 ALTER TABLE [dbo].[SYS_Company] Add Constraint DF_SYS_Company_CompanyId DEFAULT ([dbo].[f_PrimaryCode_SYS_Company]()) FOR [CompanyId] --Go --删除约束 Alter table SY

  • Sql Server数据把列根据指定内容拆分数据的方法实例

    今天由于工作需要,需要把数据把列根据指定的内容拆分数据 其中一条数据实例 select id , XXXX FROM BIZ_PAPER where  id ='4af210ec675927fa016772bf7dd025b0' 拆分方法: select t3.id ,t3.XXXX as XXXX from ( select A.id , B.XXXX from ( SELECT id, XXXX = CONVERT(xml,'<root><v>' + REPLACE(XXXX

  • 通过Python实现对SQL Server 数据文件大小的监控告警功能

    1.需求背景 系统程序突然报错,报错信息如下: The transaction log for database '@dbname' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases 此时查看log文件,已达2T. 当时的紧急处理方案是,移除掉镜像,修改数据库恢复模式(由full修改为simple),收缩日志. 为了防止类似

  • Navicat连接SQL Server数据:报错08001-命名管道提供程序的完美解决方法

    新安装了SQL server用Navicat进行连接时出现下面的问题 首先用SQL server自带的GUI用windows认证的方式进入,重新配置了登录名和登录密码分别为CDSS和CDSS,之后直接采用此登录名和登录密码发现还是连不上,后来的解决办法是,把服务重新启动一下. 修改配置登录名后需要重启一下服务?好像有那么点道理,注意是重启服务而不仅仅是重启GUI. mark一下服务列表的打开路径:开始→控制面板→系统和安全→管理工具→服务 还有一个是SQL server配置管理器,打开网络配置,

  • SQL Server 数据文件收缩和查看收缩进度的步骤

    目录 回收步骤: 1.查看日志文件大小[一般回收比较大的] 2.查看日志文件空间是否可回收[只有log_reuse_wait_desc是NOTHING状态才可回收] 3.回收日志文件空间 4.查看数据文件大小 5.收缩数据文件[按照经验,最好每5G循环收缩,如果影响业务,随时中断,不会回滚] 6.查看收缩进度[预估值] SQL Server在删除数据后,会重新利用这部分空间,所以如果不是空间紧张的情况下,可以不回收. 回收一般先回收日志文件,因为这个回收速度非常快,可以短时间内清理出一部分可用空

  • SQL Server在AlwaysOn中使用内存表的“踩坑”记录

    前言 最近因为线上alwayson环境的一个数据库上使用内存表.经过大概一个星期监控程序发现了一个非常严重问题这个数据库的日志文件不会截断,已用空间一直在增加(存在定时的每个小时的日志备份),同时内存表数据库文件也无法删除,下面就介绍一下后面我的处理过程,话不多说了,来一起看看详细的介绍吧. 数据库:SQL Server2014 Enterprise Edition (64-bit) 删除文件 使用一个单独非alwayson环境的数据库测试. 一.创建内存表 ---创建内存表文件组 ALTER

随机推荐