您的位置:首页 > 大数据 > 人工智能

Wait--常见的等待类型

2014-01-17 17:28 204 查看
--==================================================================================
--SLEEP_BPOOL_FLUSH

MSDN上如是说:当检查点为了避免磁盘子系统泛滥而中止新 I/O 的发布时出现。

场景:
在做以下操作时
1. 在修改数据库属性,如修改还原恢复模式简单为完整,长时间不能运行完毕
2. 还原数据库时,消息提示100% 但是在运行

经过调查,发现等待为SLEEP_BPOOL_FLUSH,进一步调查,发现该数据库上及其容易产生脏页(修改1W条记录可能会照成2W的脏页)

解决办法:
1. 将数据量较大的表和索引拆分(或分区)或归档历史数据
2. 建立合适索引或修改索引字段顺序

--==================================================================================
--LCK_M_XX
由于资源被加锁而导致其线程因锁不兼容造成阻塞

造成的原因
1>不合理的事务隔离级别
2>过大的事务长期占有某些资源
3>执行效率不高的语句

解决方案
1>设置合理的事务隔离级别
2>使用乐观并发
3>读写分离
4>优化DML语句,建立合理的索引
5>避免使用不合理的锁提示
6>查找造成阻塞的其他原因

--==================================================================================
--PAGELATCH_XX

等待访问内存中的页面

PAGELATCH_XX与PAGEIOLATCH_XX完全不同

解决TempDB上的PAGELATCH_XX方案
1>启用TF 1118 来阻止将新创建的表放入混合区
2>增加文件个数来减少对系统分配页的争抢
3>不要显示Drop临时表来减少非非配页的争抢(存储过程中的临时表可以被重用)

解决页拆分引起的问题
1>GUID类型的索引键造成的页拆分,设置合适的填充因子或修改GUID键
2>数据变化过大引起的页拆分,将变化较大(长度)且变化频率较高的列拆分到其他表
3>控制索引键的长度

解决高并发插入自增表导致的插入热点
1>使用随机或组合键来将数据分散到表中各个部分而不是尾部
2>修改架构,将数据插入到多个表中或多个数据库中

--==================================================================================
--WRITELOG
等待将日志快flush到日志文件

可能原因
1>导致大量事务日志的操作产生,如果索引维护
2>事务并发度较高
3>IO系统瓶颈
4>频繁页拆分

解决方案
1>查看LOGBUFFER等待,是否存在对日志缓冲区的争抢
2>查看日志所在磁盘是否存在队列
3>查看事务平均大小,是否存在小事务频繁操作,将小事务合并为大事务
4>删除无用索引
5>业务拆分,由多个数据库来承担压力
6>提高日志磁盘的性能
7>修改索引,减少页分裂

--==================================================================================
--ASYNC_NETWORK_IO
当返回查询结果给客户端时,客户端未能及时处理

可能原因
1>网络不佳导致传输速率低
2>客户端程序处理数据存在问题
3>服务端返回过多数据

解决方案
1>修改客户端程序,避免出现RBAR(Row by agonizing Row)
2>避免一次返回给客户端过多数据,如果分页等
3>检查网络路由
4>检查网络硬件

--==================================================================================
--PAGEIOLATCH_XX

常见的有PAGEIOLATCH_SH和PAGEIOLATCH_EX,在数据页从磁盘读取到内存中发生等待,SH表示数据页用于读取,EX表示数据页用于修改

可能导致的原因
1>IO系统的确存在问题,存在IO瓶颈
2>执行计划不佳导致扫描
3>内存存在压力导致页在内存中的存活时间过短

解决方案:
1>检查执行计划
2>检查是否存在内存压力
3>检查是否存在其他应用导致IO压力
4>检查存储是否满足需求

--==================================================================================
--CXPACKET
在执行并行查询计划时,由于各并行线程之间任务分配不均匀或某个线程被阻塞,导致CXPACKET 值增加

导致CXPACKET等待高的原因有很多,不能盲目地修改 MAXDOP的值或修改实例级别的最大并发度
可能原因有:
1>统计过期导致生成低效的执行计划
2>缺乏索引导致表扫描
3>中间结果集无法预估结果集行数,导致执行计划低效
4>某个线程因其他资源被阻塞

解决方案
1>检查执行计划是否高效
2>修改语句的并发度
3>修改实例级别的最大并发度

补充:
建议将MAXDOP的值设置为小于逻辑CPU的数,以避免单个查询阻塞所有请求
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: