SQL Server应用模式之OLTP系统性能分析
OLTP系统的最大特点,是这类应用里有大量的,并发程度比较高的小事务,包括SELECT、INSERT、UPDATE和DELETE。 这些操作都比较简单,事务时间也不会很长,但是要求的返回时间很严格,基本上需要在几秒钟内必须返回。
支持生产流水线的数据库应用,是很典型的OLTP系统。一件产品从原材料到组装成最后的产品,中间会有很多道工序。每道工序本身不复杂,不会花很多时间。工厂需要使用数据库应用记录和监督每一道工序。在流水线上,工人可以扫描产品上的条形码,快速的输入产品加工、处理或检验结果。这些输入和修改过程都会很简单,而且很多在数据库里会是INSERT、UPDATE或DELETE动作。但是应用的响应速度要求非常高,最后等待的时间可以忽略不计。如果工人输入一个条形码以后要等几秒钟,很多他在处理每一件产品的时候,都会多花几秒钟。如果他要花几十秒,那么整个流水线的运转就会很慢。如果系统出了问题,他每处理一个产品都要花几分钟,那么流水线就会瘫痪,工人们都可以去喝茶了。数据库管理员这时将面对的是心急如焚的管理高层。
所以OLTP系统在设计的时候,要非常小心,像那种由于一条语句而导致整个服务器范围的阻塞,是绝对要避免的。
OLTP系统要注意避免出现的问题主要提现在以下几个方面。
规则 |
性能计数器值 |
阈值 |
检查目标 |
问题描述 |
1 |
经常运行的语句超过4个表格Join |
>4张表 |
sys.dm_exec_sql_text |
如果经常运行的语句要做多张表的Join,可以考虑降低数据库设计范式级别,增加一些冗余字段,用空间换取数据库效率。 |
2 |
经常更新的表格有超过3个索引 |
>3个索引 |
sys.indexes |
索引太多会影响更新效率 |
3 |
语句会做大量IO |
>1 |
a. 性能计数器SQLServer:Access Methods - Full Scans/sec 和 Range Scans/sec 比较高。 |
语句缺少合适的索引 |
4 |
未被使用的索引 |
所有没有在sys.dm_db_index_usage_stats这个DMV里出现的索引 |
避免定义没有用的索引,凭空增加SQL Server的维护负担 |
建议查询1.1 |
--返回最经常运行的条语句 SELECT TOP 100 |
建议查询1.2 |
--返回最经常被修改的个索引 --通过它们的DataBase_id、object_id、index_id和partition_number --可以找到他们是哪个数据库上的哪个索引 SELECT TOP 100 * |
建议查询1.3 |
--返回做I/O数目最多的条语句及它们的执行计划 SELECT TOP 50 (total_logical_reads/execution_count) AS avg_logical_reads |
规则 |
性能计数器值 |
阈值 |
检查目标 |
问题描述 |
1 |
Signal Waits |
>25% |
sys.dm_os_wait_stats |
指令等待CPU资源的时间占总时间的百分比。如果超过25%,说明CPU资源紧张 |
2 |
执行计划重用率 |
<90% |
性能计数器SQLServer:Statistics下 |
OLTP系统的核心语句,必须有大于95%的执行计划重用率 |
3 |
并行运行的Cxpacket等待状态 |
>5% |
sys.dm_os_wait_stats |
首先,并行运行意味着SQL Server在处理一句代价很大的语句,要不就是没有合适的索引,要不就是筛选条件没能够筛选掉足够的记录,使得语句要返回大量的结果。这个在OLTP系统里都是不容许的。 |
建议查询2.1 |
-- 计算signal |
计算方法2.1 |
性能计数对象SQLServer:SQL Statistics 下面有几个计数器,可以计算出大致的执行计划重用率。计算方法是: Initial Compilations = SQL Compilations/sec – SQL Re-Compilations/sec 执行计划重用率 = (Batch request/sec – Initial Compilations/sec)/Batch requests/sec |
建议查询2.2 |
--计算'Cxpacket'占整wait时间的百分比 DECLARE @Cxpacket bigint |
规则 |
性能计数器值 |
阈值 |
检查目标 |
问题描述 |
1 |
Page Life Expectancy |
<300 sec |
性能计数器 |
OLTP系统的操作都比较简单,所以它们不应该要访问太多的数据。如果数据也不能长时间的缓存在内存里,势必会影响性能,同事也说明了某些语句没有合适的索引 |
2 |
Page Life Expectancy |
经常会下降50% |
性能计数器SQL Server Buffer Manager |
问题同上 |
3 |
Memory Grants Pending |
>1 |
性能计数器 SQL Server Memory Manager |
等待内存分配的用户数目,如果大于1,一定有内存压力 |
4 |
SQL cache hit ratio |
<90% |
性能计数器 |
这个值不能长时间(例如,60秒钟)地小于90%。否则常常意味着有内存压力 |
规则 |
性能计数器值 |
阈值 |
检查目标 |
问题描述 |
1 |
Average Disk sec/read |
>20ms |
性能计数器 |
在没有I/O压力的情况下,读操作应该在4~8ms以内完成 |
2 |
Average Disk sec/write |
>20ms |
性能计数器 |
对于像日志文件这样的连续写,应该在1ms以内完成 |
3 |
Big Ios |
>1 |
性能计数器 |
语句缺少合适的索引 |
4 |
排在前两位的等待状态有下面几个: |
Top2 |
SELECT TOP 2 wait_type |
这些等待状态意味着有I/O等待 |
阻塞问题在OLTP系统里危害巨大,是要严格避免的。
规则 |
性能计数器值 |
阈值 |
检查目标 |
问题描述 |
1 |
阻塞发生频率 |
>2% |
sys.dm_db_index_operational_stats(建议查询5.1) |
阻塞发生频率 |
2 |
阻塞事件报告 |
30s |
sp_configure 'blocked process threshold' |
在SQL Trace里自动报告超过30秒钟的阻塞语句 |
3 |
平均阻塞时间 |
>100ms |
sys.dm_db_index_operational_stats(建议查询5.1) |
阻塞发生的长短 |
4 |
排在前两位的等待状态以这样开头LCK_M_?? |
Top2 |
SELECT TOP 2 wait_type |
说明系统经常有阻塞 |
5 |
经常有死锁 |
每个小时超过5个 |
打开Trace Flag 1204,或者在SQL Trace里跟踪相关时间 |
死锁往往伴随着阻塞同时发生 |
建议查询5.1 |
--查询当前数据库上所有用户表格在Row |
规则 |
性能计数器值 |
阈值 |
检查目标 |
问题描述 |
1 |
网络有延时,或者应用太频繁地和数据库交互 |
Output queue length >2 |
性能计数器 |
网络不能支持应用和数据库服务器的交互流量 |
2 |
网络带宽用尽 |
Packets Outbound Discarded; |
性能计数器 |
由于网络太忙,有packet在传输中丢失 |
总之,对于一个要处理大量小型事务请求的OLTP系统,其事务请求的相应速度与资源配置优化可以从下面几方面着手。
1) 对于会经常发生INSERT、UPDATE和DELETE的表格,在设计的时候要选择最小数量的索引。
2) 可以通过提高执行计划重用降低JOIN的数目降低CPU使用率。
3) 可以通过优化索引设计,降低JOIN数目和提高页面的内存里缓存生命周期,环节IO瓶颈。
4) 如果Page Life Expectancy不会突然下降的话,说明内存的DataBase
Page部分没有瓶颈。
5) 可以通过优化索引和缩短事务大小来减少阻塞
SQL Server应用模式之OLTP系统性能分析的更多相关文章
- SQL Server 2016中In-Memory OLTP继CTP3之后的新改进
SQL Server 2016中In-Memory OLTP继CTP3之后的新改进 转译自:https://blogs.msdn.microsoft.com/sqlserverstorageengin ...
- SQL Server中模式(schema)、数据库(database)、表(table)、用户(user)之间的关系
数据库的初学者往往会对关系型数据库模式(schema).数据库(database).表(table).用户(user)之间感到迷惘,总感觉他们的关系千丝万缕,但又不知道他们的联系和区别在哪里,对一些问 ...
- 需要我们了解的SQL Server阻塞原因与解决方法
需要我们了解的SQL Server阻塞原因与解决方法 上篇说SQL Server应用模式之OLTP系统性能分析.五种角度分析sql性能问题.本章依然是SQL性能 五种角度其一“阻塞与死锁” 这里通过连 ...
- SQL Server 内存中OLTP内部机制概述(四)
----------------------------我是分割线------------------------------- 本文翻译自微软白皮书<SQL Server In-Memory ...
- SQL Server 内存中OLTP内部机制概述(三)
----------------------------我是分割线------------------------------- 本文翻译自微软白皮书<SQL Server In-Memory ...
- SQL Server 内存中OLTP内部机制概述(二)
----------------------------我是分割线------------------------------- 本文翻译自微软白皮书<SQL Server In-Memory ...
- SQL Server 内存中OLTP内部机制概述(一)
----------------------------我是分割线------------------------------- 本文翻译自微软白皮书<SQL Server In-Memory ...
- [转]SQL Server 性能调优(内存)
存储引擎自调整 sql server 是如何分配内存的 32bit地址空间的限制 用户模式vas分配和virtualalloc 非boffer pool 分配内存(保留内存) VAS调整 AWE ...
- sql server中常用方法函数
SQL SERVER常用函数 1.DATEADD在向指定日期加上一段时间的基础上,返回新的 datetime 值. (1)语法: DATEADD ( datepart , number, date ) ...
随机推荐
- SGU 485 Arrays
485. Arrays Time limit per test: 1.75 second(s)Memory limit: 262144 kilobytes input: standardoutput: ...
- [K/3Cloud]有关单据显示行数限制和数据导出的建议
1.针对显示行数限制: 模仿现在很流行的"查看更多"的模式,动态加载数据. 我相信这一点建议别人也提过,还请总部对此开展头脑风暴,因为在实际使用中客户总是不理解为何要限制行数,解释 ...
- 开源的多行字符串工具: 在JS中整段地写HTML
这样看来ES6的多行字符模板可能就不需要了-- 通过这个你可以整段整段地在JS中写HTML.SQL了. 示例 之前你得这样写 var str = '' +'<!doctype html>' ...
- JAVA虚拟机运行时内存划分--运行时数据区域
Java虚拟机在执行java程序时会把内存划分为以下几个不同的数据区域: java虚拟机内存划分(运行时)1.线程私有的: 程序计数器(Program Counter Register):可以看作当前 ...
- JSP计数器
1.JSP弥补了servlet页面显示的不足:jsp运行时候需要转化为servlet,本质上就是servlet:tomcat下的work目录下有jsp的servlet和对应的class文件;下次再调用 ...
- MySQL: 打开binlog选项后无法重启MySQL
binlog目录权限不足导致,用chown mysql:mysql <log folder>即可解决此问题.
- 【CV论文阅读】Dynamic image networks for action recognition
论文的重点在于后面approximation部分. 在<Rank Pooling>的论文中提到,可以通过训练RankSVM获得参数向量d,来作为视频帧序列的representation.而 ...
- SuperSwipeRefreshLayout 一个功能强大的自己定义下拉刷新组件
SuperSwipeRefreshLayout 一个功能强大的自己定义下拉刷新组件. Why? 下拉刷新这样的控件.想必大家用的太多了,比方使用非常多的XListView等. 近期.项目中非常多列表都 ...
- 转 java synchronized详解
转自 http://www.cnblogs.com/GnagWang/archive/2011/02/27/1966606.html Java语言的关键字,当它用来修饰一个方法或者一个代码块的时候,能 ...
- 数据库数据在Java占用内存简单估算
数据库数据在Java占用内存简单估算 结论: 1.数据库记录放在JAVA里,用对象(ORM一般的处理方式)须要4倍左右的内存空间.用HashMap这样的KV保存须要10倍空间; 2.假设你主要数据是t ...