疑难杂症--SQL SERVER 2012下数据库内存异常回收
2014-05-26 21:46
260 查看
--===================================================================
--背景:
在一台SQL SERVER 2012 SP1(11.0.3000)服务器上,由于批处理请求较高,CPU使用率超过40%,于是开始各种调研。。
服务器情况:
服务器物理内存为128GB, 分配给SQL SERVER 115GB,Windows 可用物理内存为6GB左右
压力情况:
批处理请求超过30000+,有大量UPDATE和INSERT操作,CPU使用率超过40%,IO队列在20以上。
--===================================================================
首先查看当前运行的SQL,查看是否有可优化的SQL
View Code
经过分析,未发现执行时间较长或耗CPU较多的执行计划,但发现有大量的写日志等待情况和一些等待IO的操作,于是分析IO
查询发现除日志文件(FILE_ID=2)外,还有其他文件也有IO操作,多次执行发现对非日志文件的IO操作频率较高,于是怀疑存在内存压力,导致数据被频繁换入换出,从而导致IO操作。
由于system_memory_state_desc显示为“Available physical memory is high”,表明内存没有压力。
查看BUFFER POOL 的使用情况
其中MEMORYCLERK_SQLBUFFERPOOL使用40多GB,而max server memory (MB)被设置为115GB, 参考数据库的大小(800GB)和访问情况(频繁更新),我们预估活跃数据应该比较多,BUFFER POOL应该占用更多的内存,于是我们进一步分析各数据库的内存使用
发现数据库使用的内存的确不高,查看相关性能计数器
发现Page life expectancy 的值很低,表明有内存压力。
经过一段时间的观察发现,各数据库使用的内存会突然被释放,从四五十GB突然释放到十几个GB,为此百思不得其解,于是请何雷何大师出马,何大师先使用语句进行简单的验证后,着手使用windows的性能计数器来分析问题,由于我们关注点放在内存上,因此性能计数器只选择SQLServer:Buffer Manager和SQLServer:Memory Manager,通过一段时间的数据抓取,发现SQLServer:Memory Manager下的Database Cache Memory(kb)数据周期性出现直线下降,而对应的SQLServer:Buffer Manager下的Lazy Write/Sec也有明显变化,因此猜测该时间点有Lazy Write,导致释放大量数据页,并使得Page life expectancy变得很低,而由于数据频繁修改,从而又导致数据库占用内存缓慢增长,直到下一次突然下降。
由于性能计数器的频率设置为1秒(何大师设定的,换我设置的话,我估计会设置为10秒,估计Lazy Write就会被忽略掉),因此我们很容易找出问题发生的时间点和周期频率,通过查询作业,发现日志传送的备份时间和周期与这完全吻合,初步断定有日志传送引起,修改日志传送的备份执行频率,我们发现该问题的出现频率也随之变化,因此可以确定日志传送导致。
调查进行到这一步,相信很多人会考虑移除日志传送(换我我也会这么干),而何大师第一时间点选择了查询SQL SERVER 相关的BUG,并成功找到解决办法(与大师差距就在这里体现),原来在系统压力较大的情况下,SQL SERVER的内存回收机制可能出现问题,引发内存回收并回收超过需求的大量内存。
该BUG相关描述和解决办法
--=========================================
PS1:正常情况下,当数据库存在内存压力,SQL SERVER 会释放一部分BUFFER POOL中的数据页,从而保证SQL SERVER 有一定的空闲页,如果空闲页的数量太多会导致内存利用率低,而如果空闲页的数量过低会导致频繁地内存申请等待。本案例中的情况就属于释放过多数据页导致。
PS2:由于该问题是日志传送中的备份作业诱发,而备份使用的不是SQL SERVER 外部内存,因此我们曾怀疑是外部内存压力所导致,尝试降低max server memory (MB)来使Windows有更多的可用内存(从原来的5GB左右增大到20GB左右),后发现该操作并不能解决此问题。
PS3:一部分DBA同仁(包括我和我以前的一些同事)在遇到问题时总是从自身操作查找原因,却忽略了查找SQL SERVER BUG,做了很多无用功还解决不了问题。
PS4:除了在安装SQL SERVER时会考虑打补丁外,我此前就从不关注补丁及其最新动态,在以往和一些高手们讨论问题时,他们经常会提及某某补丁修复了某某bug,让我很惊奇,现在知道差距所在!
--========================================
乱七八糟地写了一堆,主要是想记录下处理问题的过程,学习别人处理的思路,找到自己不足的地方,如有不对,望诸君及时拍砖指点!
--========================================
惯例依旧是妹子
--背景:
在一台SQL SERVER 2012 SP1(11.0.3000)服务器上,由于批处理请求较高,CPU使用率超过40%,于是开始各种调研。。
服务器情况:
服务器物理内存为128GB, 分配给SQL SERVER 115GB,Windows 可用物理内存为6GB左右
压力情况:
批处理请求超过30000+,有大量UPDATE和INSERT操作,CPU使用率超过40%,IO队列在20以上。
--===================================================================
首先查看当前运行的SQL,查看是否有可优化的SQL
--================================================== --查看正在执行的SQL SELECT s.[session_id], r.[start_time], DATEDIFF(SECOND,r.start_time,GETDATE()) AS elapsed_seconds, r.[status] AS RequestStatus, DB_NAME(r.database_id) AS DatabaseName, r.[wait_type], r.[wait_resource], r.[wait_time], r.[reads], r.[writes], r.[logical_reads], s.[status] AS SessionStatus, s.[host_name], s.[original_login_name], s.[nt_user_name], s.[program_name], s.[client_interface_name], c.[client_net_address], SUBSTRING (qt.text, r.statement_start_offset/2, (CASE WHEN r.statement_end_offset = -1 THEN LEN(CONVERT(NVARCHAR(MAX), qt.text)) * 2 ELSE r.statement_end_offset END - r.statement_start_offset)/2) AS ExecutingSQL, qp.query_plan FROM sys.dm_exec_requests r INNER JOIN sys.dm_exec_sessions s ON r.session_id=s.session_id LEFT JOIN sys.dm_exec_connections c ON c.session_id=s.session_id CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) as qt CROSS APPLY sys.dm_exec_query_plan(r.plan_handle) as qp
View Code
经过分析,未发现执行时间较长或耗CPU较多的执行计划,但发现有大量的写日志等待情况和一些等待IO的操作,于是分析IO
--===================================================== --查看当前挂起的IO请求 SELECT DB_NAME(S.database_id) AS DBName, S.file_id, S.io_stall, R.io_pending_ms_ticks FROM sys.dm_io_pending_io_requests R INNER JOIN sys.dm_io_virtual_file_stats(NULL,NULL) S ON R.io_handle=S.file_handle
查询发现除日志文件(FILE_ID=2)外,还有其他文件也有IO操作,多次执行发现对非日志文件的IO操作频率较高,于是怀疑存在内存压力,导致数据被频繁换入换出,从而导致IO操作。
--===================================== --查看内存状态 SELECT m.total_physical_memory_kb, m.available_physical_memory_kb, m.total_page_file_kb, m.available_page_file_kb, m.system_memory_state_desc FROM sys.dm_os_sys_memory m
由于system_memory_state_desc显示为“Available physical memory is high”,表明内存没有压力。
查看BUFFER POOL 的使用情况
--========================================================= --查看各内存对象使用内存情况 --在SQL SERVER 2012及以上版本运行 SELECT M.type, sum(M.virtual_memory_reserved_kb) AS VirtualMemoryReservedKB, SUM(M.virtual_memory_committed_kb) AS VirtualMemortCommitedKB, SUM(M.shared_memory_committed_kb) AS SharedMemroyCommittedKB, SUM(M.shared_memory_reserved_kb) AS SharedMemroyReservedKB, SUM(M.pages_kb) AS PagesKB FROM sys.dm_os_memory_clerks M GROUP BY M.type ORDER BY PagesKB DESC --========================================================= --查看各内存对象使用内存情况 --在SQL SERVER 2012以下版本运行 SELECT M.type, SUM(M.virtual_memory_reserved_kb) AS VirtualMemoryReservedKB, SUM(M.virtual_memory_committed_kb) AS VirtualMemortCommitedKB, SUM(M.shared_memory_committed_kb) AS SharedMemroyCommittedKB, SUM(M.shared_memory_reserved_kb) AS SharedMemroyReservedKB, SUM(M.multi_pages_kb) AS MultiPagesKB, SUM(M.single_pages_kb) AS SinglePagesKB, SUM(M.multi_pages_kb)+SUM(M.single_pages_kb) AS TotalPagesKB FROM sys.dm_os_memory_clerks M GROUP BY M.type ORDER BY TotalPagesKB DESC
其中MEMORYCLERK_SQLBUFFERPOOL使用40多GB,而max server memory (MB)被设置为115GB, 参考数据库的大小(800GB)和访问情况(频繁更新),我们预估活跃数据应该比较多,BUFFER POOL应该占用更多的内存,于是我们进一步分析各数据库的内存使用
--========================================================= --查看各数据库的内存使用情况 SET TRAN ISOLATION LEVEL READ UNCOMMITTED SELECT ISNULL(DB_NAME(database_id), 'ResourceDb') AS DatabaseName , CAST(COUNT(row_count) * 8.0 / (1024.0) AS DECIMAL(28,2)) AS [Size (MB)] FROM sys.dm_os_buffer_descriptors GROUP BY database_id ORDER BY DatabaseName
发现数据库使用的内存的确不高,查看相关性能计数器
--=============================================== --查看数据库内存相关性能计数器 SELECT * , CAST(P.cntr_value*8.0/1024.0 AS INT) AS MemoryMB FROM sys.sysperfinfo p WHERE p.object_name LIKE '%SQLServer:Buffer Manager%' SELECT * , CAST(P.cntr_value*8.0/1024.0 AS INT) AS MemoryMB FROM sys.sysperfinfo p WHERE p.object_name LIKE '%SQLServer:Memory Manager%'
发现Page life expectancy 的值很低,表明有内存压力。
经过一段时间的观察发现,各数据库使用的内存会突然被释放,从四五十GB突然释放到十几个GB,为此百思不得其解,于是请何雷何大师出马,何大师先使用语句进行简单的验证后,着手使用windows的性能计数器来分析问题,由于我们关注点放在内存上,因此性能计数器只选择SQLServer:Buffer Manager和SQLServer:Memory Manager,通过一段时间的数据抓取,发现SQLServer:Memory Manager下的Database Cache Memory(kb)数据周期性出现直线下降,而对应的SQLServer:Buffer Manager下的Lazy Write/Sec也有明显变化,因此猜测该时间点有Lazy Write,导致释放大量数据页,并使得Page life expectancy变得很低,而由于数据频繁修改,从而又导致数据库占用内存缓慢增长,直到下一次突然下降。
由于性能计数器的频率设置为1秒(何大师设定的,换我设置的话,我估计会设置为10秒,估计Lazy Write就会被忽略掉),因此我们很容易找出问题发生的时间点和周期频率,通过查询作业,发现日志传送的备份时间和周期与这完全吻合,初步断定有日志传送引起,修改日志传送的备份执行频率,我们发现该问题的出现频率也随之变化,因此可以确定日志传送导致。
调查进行到这一步,相信很多人会考虑移除日志传送(换我我也会这么干),而何大师第一时间点选择了查询SQL SERVER 相关的BUG,并成功找到解决办法(与大师差距就在这里体现),原来在系统压力较大的情况下,SQL SERVER的内存回收机制可能出现问题,引发内存回收并回收超过需求的大量内存。
该BUG相关描述和解决办法
--=========================================
PS1:正常情况下,当数据库存在内存压力,SQL SERVER 会释放一部分BUFFER POOL中的数据页,从而保证SQL SERVER 有一定的空闲页,如果空闲页的数量太多会导致内存利用率低,而如果空闲页的数量过低会导致频繁地内存申请等待。本案例中的情况就属于释放过多数据页导致。
PS2:由于该问题是日志传送中的备份作业诱发,而备份使用的不是SQL SERVER 外部内存,因此我们曾怀疑是外部内存压力所导致,尝试降低max server memory (MB)来使Windows有更多的可用内存(从原来的5GB左右增大到20GB左右),后发现该操作并不能解决此问题。
PS3:一部分DBA同仁(包括我和我以前的一些同事)在遇到问题时总是从自身操作查找原因,却忽略了查找SQL SERVER BUG,做了很多无用功还解决不了问题。
PS4:除了在安装SQL SERVER时会考虑打补丁外,我此前就从不关注补丁及其最新动态,在以往和一些高手们讨论问题时,他们经常会提及某某补丁修复了某某bug,让我很惊奇,现在知道差距所在!
--========================================
乱七八糟地写了一堆,主要是想记录下处理问题的过程,学习别人处理的思路,找到自己不足的地方,如有不对,望诸君及时拍砖指点!
--========================================
惯例依旧是妹子
相关文章推荐
- SQL SERVER 2012下数据库内存异常回收
- SQL Server 2012笔记分享-14:数据库内存设置 推荐
- 利用虚拟硬盘(把内存当作硬盘)来提高数据库的效率(目前只针对SQL Server 2000)可以提高很多
- 利用虚拟硬盘(把内存当作硬盘)来提高数据库的效率(目前只针对SQL Server 2000)可以提高很多
- 由于文件不可访问,或者内存或磁盘空间不足,所以无法打开数据库 'msdb'。有关详细信息,请参阅 SQL Server 错误日志。 (Microsoft SQL Server,错误: 945)
- 使用Dpm 2012 Sp1备份SQL server 2012数据库的报错一例
- sql server 2012 数据库所有表里查找某字符串的方法
- 有关SQLServer内存问题(收藏)-数据库专栏,SQL Server
- 为SQL Server 2012配置镜像注意事项及采用SSD硬盘作为数据库存储磁盘
- 初探SQL Server 2012 包含数据库
- 初探SQL Server 2012 包含数据库
- 如何使用sql语句创建数据库–SQL Server 2012 (Win 8)
- 异常:无法连接到 SQL Server 数据库。-解决办法
- sql server 2012 新功能(2) 内存中的列存储(“Apollo”)
- 网狐架设,中心服务器错误数据库异常:[DBNETLIB][ConnectionOpen (Connect()).]SQL Server 不存在或拒绝访问
- SQL Server 2012 内存计数器的变化
- 自动定时重启sql server回收内存
- provider:共享内存提供程序,error:0-管道的另一端上无任何进程(sqlserver 2005数据库异常)
- SQL Server 2012中包含的数据库(Contained Database)探索
- SQL Server 2012 数据库数据导出为脚本