JAVA高级面试进阶训练营视频教程

admin

--===================================================================

--背景：

在一台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，让我很惊奇，现在知道差距所在！

--========================================

乱七八糟地写了一堆，主要是想记录下处理问题的过程，学习别人处理的思路，找到自己不足的地方，如有不对，望诸君及时拍砖指点！

--========================================

惯例依旧是妹子