根据WaitType诊断故障

在查询执行时,等待次数和等待时间在一定程度上指示查询的瓶颈,甚至非常有助于对系统进行诊断。偶尔一次的异常等待,不足以表明系统存在瓶颈,但是,SQL Server实例经常出现特定的等待类型,并且等待时间趋于增加,这就说明,系统存在压力,或内存,或IO等,根据WaitType对系统进行监控和诊断,还能对查询进行性能调优,例如,Lock等待表明查询存在数据竞争,PageIOLatch等待表明IO响应缓慢,PageLatch等待表明文件的布局需要改进等。

一,资源信号(RESOURCE SEMAPHORE)

1,RESOURCE_SEMAPHORE 等待类型表示一个Workder等待SQL Server给予其申请的内存,以便执行Hash和Sort操作。

Used to indicate a worker is waiting to be allowed to perform an operation requiring "query memory" such as hashes and sorts .
High wait times indicate too many queries are running concurrently that require query memory. Operations requiring query memory are hashes and sorts. Use DMVs such as dm_exec_query_resource_semaphores and dm_exec_query_memory_grants

当出现 RESOURCE_SEMAPHORE 等待时,这说明查询语句请求的内存没有得到满足,就是说,该查询语句在执行Task前,需要一定量的内存资源,如果SQL Server当前的内存不足,不能分配查询语句请求的内存,将导致查询语句处于等待内存资源的状态。在SQL Server存储引擎中,排序(Sort)操作和哈希(Hash)操作是非常消耗内存资源的两个操作,优化相应的查询语句,以减少这两个操作,可以缓解SQL Server的内存压力,但在SQL Server实例中,经常出现RESOURCE_SEMAPHORE 等待,这说明SQL Server存在内存压力。

在数据库中有一个选项,Min Memory Per Query,该选项表示SQL Server为每个查询分配的最小内存,这意味着,当一个查询需要额外的内存资源,该查询获取的内存大小,很大部分是由该选项决定的,只有为每个查询授予一定的内存之后,该查询语句才会真正开始执行。

2,发送RESOURCE SEMAPHORE用于授予请求内存(Requested Memory)

当SQL Server实例收到用户的查询请求时,SQL Server优化器首先创建编译计划(Complied Plan),根据编译计划再创建执行计划(Execution Plan)。当SQL Server优化器创建编译计划时,它需要计算查询在执行时需要消耗的内存,用于执行查询的内存分为必需内存(Required Memory)和额外内存(Additional Memory)。必需内存是指SQL Server实例执行Sort或Hash操作时必须分配的最小内存,如果没有分配必需内存,查询请求不会执行。额外内存是查询用于存储临时的中间数据的内存,如果SQL Server没有足够的内存,查询将临时数据存储在硬盘中,这会降低查询性能。

SQL Server 要授予每个查询多少内存,查询才能真正开始执行呢?

  • Step1,计算需要的内存(Needed Memory):SQL Server计算每个查询需要多少内存才能执行,这通常是必需内存和额外内存之和,当查询请求以并发方式执行时,需要的内存公式是:(RequiredMemory*DOP)+额外内存。
  • Step2,计算请求的内存(Requested Memory):SQL Server检查每个查询请求需要的内存数量是否超出系统的限制,SQL Server减少额外内存的数量,以致于不会超出系统的上限,这个最终的内存数量是查询语句得以执行的请求内存。
  • Step3,为查询分配请求内存:SQL Server实例发送资源信号(RESOURCE SEMAPHORE),为查询(Query)授予/分配请求的物理内存。

当资源信号发送之后,如果SQL Server实例不能被授予查询的请求内存,那么查询将处于RESOURCE_SEMAPHORE 等待状态。SQL Server维护一个先入先出( first-come-first-served)的等待队列,当新的查询处于RESOURCE_SEMAPHORE 等待状态,SQL Server将该查询放入队列的末尾。一旦SQL Server实例找到足够的空闲内存,那么SQL Server取出RESOURCE_SEMAPHORE 等待队列顶端的第一个查询,立即授予其请求的内存;该查询获得请求内存之后,开始执行查询任务;如果SQL Server实例长时间有查询处于RESOURCE_SEMAPHORE等待状态,说明SQL Server 面临内存压力。

二,调度队列信号

DISPATCHER_QUEUE_SEMAPHORE,发生当一个进程(Thread)等待处理更多的Work时,该等待是说,一个Thread处于空闲状态,等待调度去工作。如果等待时间增加,说明调度器(Dispatcher)非常空闲;该WaitType不会成为竞争资源,而将其他事务阻塞,在做Wait统计分析,可以过滤掉。

三,异步网络IO

ASYNC_NETWORK_IO等待类型,是指SQL Server 产生的结果集需要经过网络(Network)传递到客户端(Client),网络不能及时将结果集传输到Client,导致结果集仍然驻留在SQL Server的会话(Session)中,这意味着,ASYNC_NETWORK_IO 等待状态出现在SQL Server已经把数据准备好,但是网络发送速度跟不上,导致SQLServer返回的数据集仍然驻留在Session中,出现这种等待一般不是数据库的问题,调整数据库配置不会有大的帮助,网络层的瓶颈当然是一个可能的原因,对此要考虑是否真有必要返回那么多数据?所以,检查应用程序是否有必要向SQL Server申请这么大的结果集。

四,硬盘IO相关的等待

1,PageIOLatch

当缓存在buffer pool 的data page 和disk 上数据文件里的data page 进行交互时,为了保证不会有多个用户同时 read/write 内存中的buffer(a data page in memory),需要对buffer 加上PageIOLatch。PageIOLatch 是和 IO 有关,或从disk将Data page读取到内存,或从内存将Data page写入到disk。

PageIOLatch主要分为两大类:PageIOLatch_SH和PageIOLatch_EX

PageIOLatch_SH:发生在将一个Data Page从Disk 读取到内存 buffer pool 中时。当用户需要访问一个Data Page,而这个Data Page不在内存中时,Sql server 需要将 Data page 从Disk 读取到内存中,这说明内存不够大,或内存紧张,导致没有将Data Page始终缓存在内存中,SQL Server 需要过多地Page Read(从Disk读取Data page到内存 buffer pool)操作。这种情况说明内存是bottleneck。

PageIOLatch_EX:发生在用户对内存中的Data page进行了修改,SQL Server需要写回Disk,意味着disk的写入速度慢。

2,PageLatch

PageLatch 是对内存中的buffer(a data page in memory)加锁,用于同步内存 buffer Pool中的Data Page数据修改操作。当一个task需要修改 buffer时,必须申请PageLatch_EX。只有得到这个Latch,才能修改buffer里的内存。

由于buffer的修改都是在memory中完成的,所以每次修改的时间都应该非常短,而PageLatch只是在修改的过程中才会短暂出现。如果出现PageLatch等待,说明大量的并发语句在修改table,而修改操作同时集中在同一个page,或者数量不多的几个page上,这些Page 称作Hot Page。出现Hot Page 是由于数据过于集中导致,将数据分布在不同的Files上,能够减少PageLatch Wait。

3,WriteLog

和Disk的写速度有关,说明任务当前正在等待将日志记录写入日志文件,出现这个等待状态,意味着Disk的写入速度是bottleneck。

参考文档:

DISPATCHER_QUEUE_SEMAPHORE

Troubleshooting SQL Server RESOURCE_SEMAPHORE Waittype Memory Issues

Wait statistics, or please tell me where it hurts

时间: 2024-10-13 05:33:26

根据WaitType诊断故障的相关文章

RAID磁盘阵列常见故障以及修复方法

服务器数据安全有着至关重要的意义,目前大多数服务器都采用了RAID磁盘阵列技术.受服务器自身硬件局限和技术人员的操作因素,服务器无阵列无法做到100%的无故障发生.那么RAID磁盘阵列故障有哪些?RAID磁盘阵列如何进行数据恢复? 导致磁盘阵列RAID数据丢失的故障原因分为RAID逻辑层故障,RAID物理层故障以及RAID坏道层故障. 对于逻辑层故障,例如误删除,误格式化,误分区,RAID阵列信息丢失, RAID阵列信息混乱, 重新配置RAID阵列信息导致数据丢失, RAID阵列内磁盘顺序出错等

什么是车载诊断?

车载诊断(OBD)是汽车的术语,指向车辆的自我诊断和报告的能力. OBD系统给车辆所有者或维修技术员进入各个车辆子系统的状态.经由OBD诊断提供信息的数量自车载车载电脑的20世纪80年代初推出的版本有很大的差异. OBD的早期版本只会照亮故障指示灯或“白痴之光”如果检测到问题,但不会提供任何资料,说明问题的本质.现代的OBD实现使用一个标准化的数字通信端口除了标准化系列的诊断故障代码,或故障码,这允许一个快速识别和补救汽车故障提供实时数据. OBD-II诊断接头 该15031-3规范提供了两个标

IBM服务器诊断面板

IBM服务器一般会有一个服务器操作员信息面板(诊断面板),服务器一般的硬件故障都会在诊断面板上提示,但这些提示可能只是一个大概的诊断故障,有助于系统管理员更好的维护. 一.IBM X3650 M3诊断面板位置: 说明: 电源控制按钮和供电指示灯按下此按钮可手动开启和关闭服务器,或唤醒处于省电 状态下的服务器.供电指示灯的状态如下所示: A.熄灭:未接通交流电,或者电源或指示灯本身出现故障. B.快速闪烁(每秒四次):服务器已关闭,但未准备就绪,无法开启.电源控制按钮已禁用.服务器接通交流电源后大

<Autel>汽车诊断基础知识

汽车诊断器,属于车载电子,用于汽车后市场.它是诊断分析系统.汽车诊断系统,主要是ECU(电子控制单元).传感器和执行单元组成.汽车诊断器,主要是解释分析ECU中信息.初级是诊断故障码,高级是编程设码来清除码.它是在主板上诊断(OBD),通过灯的闪烁显示出来.在汽车诊断协议中,有ISO国际标准.SAE国家标准和自定义标准.如KL.PWM.VPW.CAN.光纤和以太网等协议. 诊断仪由硬件和软件组成,软件分为系统平台软件和诊断应用软件.诊断仪通过OBDII接口与ECU相通.诊断中要素有,设备.接口和

CAN诊断学习

汽车CAN总线有动力总成PCAN,底盘控制CCAN,整车控制BCAN,娱乐ECAN,诊断DCAN五种. CAN诊断,即是对CAN网络中各节点,各CAN总线,网关的故障进行检查与修复. 统一诊断服务(UDS),即ISO-14229标准,是绝大多数汽车厂商使用的诊断服务. 10:诊断会话请求服务 一般的诊断请求的输入格式为:710 02 10 01 帧ID为710,帧数据长度为8,数据长度为02,数据内容为10 01,其中10代表诊断会话发起服务,01表示默认会话 必须先发起诊断会话,类似于先建立握

柴油车J1939协议排放污染超标诊断流程和方法(技术开放)

随着电控发动机的普及,静液压驱动方式在柴油车.柴油机得到越来越多的应用,电控技术促进了柴油机的自动化和智能化,使设备状态检测变得更加简单,诊断却变得复杂.在诊断环节中,基础诊断和智慧诊断的区别在于,对多方采集的车辆检测数据,基础诊断由诊断人员分析,智慧诊断则由云计算平台进行分析和大数据案例比对,快速定位故障范围.当电控系统出现故障时,如何准确锁定故障点.快速排查故障,缩短用户等待时间.降低用户损失,是作为J1939诊断和总线数据应用必须面对和亟须解决的问题.发动机故障诊断基于SAE J1939协

88个 Linux 系统管理员必备的监控工具

随着互联网行业的不断发展,各种监控工具多得不可胜数.这里列出网上最全的监控工具.让你可以拥有超过80种方式来管理你的机器.在本文中,我们主要包括以下方面: 命令行工具 网络相关内容 系统相关的监控工具 日志监控工具 基础设施监控工具 监控和调试性能问题是一个艰巨的任务,但用对了正确的工具有时也是很容易的.下面是一些你可能听说过的工具,也有可能没有听说过——何不赶快开始试试? 八大系统监控工具 1. top 这是一个被预装在许多 UNIX 系统中的小工具.当你想要查看在系统中运行的进程或线程时:t

集群通信应用开发吐槽(2014年)

在集群通信行业两家公司开发PC应用六年了,但在对开发的理解的道路上感觉还是挺孤独的,于是想写点东西发泄下郁闷,没想到只想了一两小时就写了几十条提纲.好话说在前面,文中的提到的现象可能不全面,甚至是误会的,文中的观点更是需要审视的看待. 产品越复杂(越多硬件)越能卖出好价钱 产品便携易用,越能解决客户问题,越给客户创造价值,才越值钱.产品成本和产品价值没有直接关系,iphone的成本如果只有1元钱,就没人花45千买了? 性能问题需要测试数据来证明 在讨论某个功能的整体设计时,做嵌入式开发的常常随意

Kafka设计解析(三)- Kafka High Availability (下)

本文转发自Jason’s Blog,原文链接 http://www.jasongj.com/2015/06/08/KafkaColumn3 摘要 本文在上篇文章基础上,更加深入讲解了Kafka的HA机制,主要阐述了HA相关各种场景,如Broker failover,Controller failover,Topic创建/删除,Broker启动,Follower从Leader fetch数据等详细处理过程.同时介绍了Kafka提供的与Replication相关的工具,如重新分配Partition等