某某茶叶有限公司欢迎您!
金沙棋牌在线 > 必赢棋牌官网 > sql server 性能调优 资源等待之SOS_SCHEDULER_YIELD

sql server 性能调优 资源等待之SOS_SCHEDULER_YIELD

时间:2019-12-29 06:39

一.概述

  在前几章介绍过 sql server 性能调优资源等待之PAGEIOLATCH,PAGEIOLATCH是出现在sql server要和磁盘作交互的时候,所以加个IO两个字。这次来介绍PAGELATCH。PAGELATCH类型是sqlserver在缓冲池里的数据页面上经常加的另一类latch锁。

  既然缓冲池里的数据页面与PAGELATCH有关系,那先来介绍数据页面。

  1. 数据页面

  数据页面在"sql server 索引阐述系列二 索引存储结构"中有详细介绍,这里讲与PAGELATCH有关的知识点。 一个页面包含页头,数据存储,页尾偏移量。 在页头里包含了页面属性,页面编号,记录了当前页面空闲的起始位置,当sqlserver 在要插入的时候,就能够很快地找到插入的位置,而页尾的偏移量记录了每一条数据行所有页中的位置,当需要查找页中数据时,通过页尾的偏移量很快能定位。

  当数据行发生变化时, sql server不但要去修改数据本身,还要维护页中数据行与偏移量的关系。

       2.  PAGELATCH

  讲了这么多关于数据页面, 现在来理清一下关系, lock锁是保证数据页中数据的逻辑关系,PAGEIOLATCH的latch锁是保证数据页与磁盘进行存储的关系,  PAGELATCH的latch锁是保证数据页中数据行与页尾的偏移量的关系。当然这种区别介绍是为了更好的去理解它们之间的关系,PAGELATCH作用并不只是这点, 它还会维护系统页面如SGAM,PFS,GAM页面等。

  3. HotPage现象

  当我们为一个表创建主键自增ID时, 那么sql server将按照ID字段的值顺序进行存储,在大并发下,为了保证ID值按顺序存放在数据页中,这时PAGELATCH就会latch锁住数据页面里的存储结构, 使ID值排队保持先后顺序 。测试Hotpage现象可以是程序后端并发插入或使用 SQLIOSim工具来并发测试。

      下面来看一个简单的图:当前表里有一个page 100的页面, 该页中已有二行数据(rid1和rid2) 分别对应着页尾的偏移量1和2。 这时有二个插入任务,同时插入到page100页,假设第一个任务申请到了ex_latch锁,第二个任务就会等待,使数据行和偏移量对一 一对应。

  图片 1

  由于数据页的改动都是在内存中完成的,所以每次修改时间都应该非常短,几乎可以忽略。如果该资源成为了sql server等待的瓶颈有以下几种情况:

  (1) sql server 没有的明显的内存和磁盘瓶颈。

       (2) 大量的并发集中在表里的一个数据页上叫hotpage

       (3) tempdb 临时表也可以会成为瓶颈,通常可以通过增加tempdb文件来缓解。 具体查看Tempdb怎么会成为性能瓶颈?。

     4. 查看PAGELATCH现象

       4.1 通过sys.dm_exec_query_stats来查看实例级别的等待

select wait_type,
waiting_tasks_count,
wait_time_ms ,
max_wait_time_ms,
signal_wait_time_ms
from sys.dm_os_wait_stats
where wait_type like 'pagelatch%' 
order by  wait_time_ms desc

  图片 2

         在实例级别中等待次数最多的是PAGELATCH_EX的latch 排它锁, 平均每次耗时90毫秒,这个平均值应该是不会有性能问题。

       4.2 能过sys.dm_exec_requests 来实时查看sql语句级, 可以采用不定时监听能过session_id来获取sql 语句所对应的表,以及等待的数据页类型 。

SELECT * FROM sys.dm_exec_requests  WHERE wait_type LIKE 'pagelatch%'

   5.  解决思路

  (1)  通过设计表结构,使hotpage现象由单面的并发访问,分散到多个页面。

  (2)  如果是在identity字段上有瓶颈, 可以创建多个分区,因为每个分区都有自己的存储单位,这样hot 单页现象就分散了。

 

 一.概念

   SOS_SCHEDULER_YIELD等待类型是一个任务自愿放弃当前的资源占用,让给其他任务使用。   这个等待类型与CPU有直接关系,与内存与也有间接关系,与CPU有关系是因为在sql server里是通过任务调度SCHEDULER来关联CPU。 通过SCHEDULER下的Worker线程来处理SQL任务。为什么跟内存有关系呢,是因为获取的资源需要内存来承载。 
  Yelding的发生:是指SCHEDULER上运行的Worker都是非抢占式的, 在 SCHEDULER上Worker由于资源等待,让出当前Worker给其它Worker就叫Yielding。 关于SCHEDULER_YIELD产生的原理查看  sqlserver 任务调度与CPU。SOS_SCHEDULER_YIELD 等待的情况可以了解到:

  (1)CPU有压力

  (2) SQL Server CPU scheduler 使用得当处理就会效率高。

1.1 从实例级别来查看等待数

select wait_type,
waiting_tasks_count,
wait_time_ms ,
max_wait_time_ms,
signal_wait_time_ms
from sys.dm_os_wait_stats
where wait_type like 'SOS_SCHEDULER_YIELD%' 
order by wait_type

  查询如下图所示: 

图片 3

  这个等待类型排名第二,从请求的次数来说有69367060次,也就是说该线程用完了4ms的时间片,主动放弃cpu。如果没有大量的runnable队列或者大量的signal wait,证明不一定是cpu问题。因为这两个指标是cpu压力的一个体现。需要检查执行计划中是否存在大量扫描操作。

1.2 通过dmv scheaduler的描述查看cpu压力

SELECT scheduler_id, current_tasks_count, runnable_tasks_count, work_queue_count, pending_disk_io_count
FROM sys.dm_os_schedulers
WHERE scheduler_id < 255

  如下图所示:

图片 4

  如果你注意到runnable_tasks_count计数有两位数,持续很长时间(一段时间内),你就会知道CPU压力。两位数字通常被认为是一件坏事 无法应对当前负荷。另外可以通过性能监视器%Processor Time 来查看CPU的状况。

1.3 通过案例实时查看sql语句级的资源等待

SELECT * FROM sys.dm_exec_requests  WHERE wait_type LIKE 'SOS_SCHEDULER_YIELD%'

  -- 或查找资源等待的
  SELECT session_id ,status ,blocking_session_id
  ,wait_type ,wait_time ,wait_resource
  ,transaction_id
  FROM sys.dm_exec_requests
  WHERE status = N'suspended';

  如下图所示 运行sys.dm_exec_requests 表,由于字段多截取了三断。会话202的sql 语句上一次 等待类型是SOS_SCHEDULER_YIELD。之所以会出现YIELD,是因为SCHEDULER下的Worker已经发起了task 命令,但由于资源等待 如锁或者磁盘输入/输出等,Worker又是非抢占式,所以让出了当前的Worker。

图片 5

图片 6

图片 7

1.4 减少sos_scheduler_yield 等待

  正如上面所讨论的,这种等待类型与CPU压力有关。增加更多CPU是简单的解决方案,然而实现这个解决方案并不容易。当这个等待类型很高时,你可以考虑其他的事情。这里通过从缓存中找到与CPU相关的最昂贵的SQL语句。

--查询编译以来 cpu耗时总量最多的前50条(Total_woker_time) 第一种查询
select
'total_worker_time(ms)'=(total_worker_time/1000),
q.[text], --DB_NAME(dbid),OBJECT_NAME(objectid),
execution_count,
'max_worker_time(ms)'=(max_worker_time/1000),
'last_worker_time(ms)'=(last_worker_time/1000),
'min_worker_time(ms)'=(min_worker_time/1000),
'max_elapsed_time(ms)'=(max_elapsed_time/1000),
'min_elapsed_time(ms)'=(min_elapsed_time/1000),
'last_elapsed_time(ms)'=(last_elapsed_time/1000),
total_physical_reads,
last_physical_reads,
min_physical_reads,
max_physical_reads,
total_logical_reads,
last_logical_reads,
max_logical_reads,
creation_time,
last_execution_time
from
(select top 50 qs.* from sys.dm_exec_query_stats qs order by qs.total_worker_time desc)
as highest_cpu_queries cross apply sys.dm_exec_sql_text(highest_cpu_queries.plan_handle) as q
order by highest_cpu_queries.total_worker_time DESC

 

一.概念

  在介绍资源等待PAGEIOLATCH之前,先来了解下从实例级别来分析的各种资源等待的dmv视图sys.dm_os_wait_stats。它是返回执行的线程所遇到的所有等待的相关信息,该视图是从一个实际级别来分析的各种等待,它包括200多种类型的等待,需要关注的包括PageIoLatch(磁盘I/O读写的等待时间),LCK_xx(锁的等待时间),WriteLog(日志写入等待),PageLatch(页上闩锁)Cxpacket(并行等待)等以及其它资源等待排前的。 

  1.  下面根据总耗时排序来观察,这里分析的等待的wait_type 不包括以下

SELECT  wait_type ,
        waiting_tasks_count,
        signal_wait_time_ms ,
        wait_time_ms,
        max_wait_time_ms
FROM    sys.dm_os_wait_stats
WHERE   wait_time_ms > 0
        AND wait_type NOT IN ( 'CLR_SEMAPHORE', 'CLR_AUTO_EVENT',
                               'LAZYWRITER_SLEEP', 'RESOURCE_QUEUE',
                               'SLEEP_TASK', 'SLEEP_SYSTEMTASK',
                               'SQLTRACE_BUFFER_FLUSH', 'WAITFOR',
                               'LOGMGR_QUEUE', 'CHECKPOINT_QUEUE',
                               'REQUEST_FOR_DEADLOCK_SEARCH', 'XE_TIMER_EVENT',
                               'BROKER_TO_FLUSH', 'BROKER_TASK_STOP',
                               'CLR_MANUAL_EVENT',
                               'DISPATCHER_QUEUE_SEMAPHORE',
                               'FT_IFTS_SCHEDULER_IDLE_WAIT',
                               'XE_DISPATCHER_WAIT', 'XE_DISPATCHER_JOIN',
                               'SQLTRACE_INCREMENTAL_FLUSH_SLEEP' )
ORDER BY signal_wait_time_ms DESC

  下图排名在前的资源等待是重点需要去关注分析:

图片 8

  通过上面的查询就能找到PAGEIOLATCH_x类型的资源等待,由于是实例级别的统计,想要获得有意义数据,就需要查看感兴趣的时间间隔。如果要间隔来分析,不需要重启服务,可通过以下命令来重置

DBCC SQLPERF ('sys.dm_os_wait_stats', CLEAR);  

  wait_type:等待类型
  waiting_tasks_count:该等待类型的等待数
  wait_time_ms:该等待类型的总等待时间(包括一个进程悬挂状态(Suspend)和可运行状态(Runnable)花费的总时间)
  max_wait_time_ms:该等待类型的最长等待时间
  signal_wait_time_ms:正在等待的线程从收到信号通知到其开始运行之间的时差(一个进程可运行状态(Runnable)花费的总时间)
  io等待时间==wait_time_ms - signal_wait_time_ms

一.概述

二. PAGEIOLATCH_x

  2.1 什么是Latch

    在sql server里latch是轻量级锁,不同于lock。latch是用来同步sqlserver的内部对象(同步资源访问),而lock是用来对于用户对象包括(表,行,索引等)进行同步,简单概括:Latch用来保护SQL server内部的一些资源(如page)的物理访问,可以认为是一个同步对象。而lock则强调逻辑访问。比如一个table,就是个逻辑上的概念。关于lock锁这块在"sql server 锁与事务拨云见日"中有详细说明。

  2.2 什么是PageIOLatch 

  当查询的数据页如果在Buffer pool里找到了,则没有任何等待。否则就会发出一个异步io操作,将页面读入到buffer pool,没做完之前,连接会保持在PageIoLatch_ex(写)或PageIoLatch_sh(读)的等待状态,是Buffer pool与磁盘之间的等待。它反映了查询磁盘i/o读写的等待时间。
  当sql server将数据页面从数据文件里读入内存时,为了防止其他用户对内存里的同一个数据页面进行访问,sql server会在内存的数据页同上加一个排它锁latch,而当任务要读取缓存在内存里的页面时,会申请一个共享锁,像是lock一样,latch也会出现阻塞,根据不同的等待资源,等待状态有如下:PAGEIOLATCH_DT,PAGEIOLATCH_EX,PAGEIOLATCH_KP,PAGEIOLATCH_SH,PAGEIOLATCH_UP。重点关注PAGEIOLATCH_EX(写入)和PAGEIOLATCH_SH(读取)二种等待。

2.1  AGEIOLATCH流程图

  有时我们分析当前活动用户状态下时,一个有趣的现象是,有时候你发现某个SPID被自己阻塞住了(通过sys.sysprocesses了查看) 为什么会自己等待自己呢? 这个得从SQL server读取页的过程说起。SQL server从磁盘读取一个page的过程如下:

图片 9

图片 10

  (1):由一个用户请求,获取扫描X表,由Worker x去执行。

  (2):在扫描过程中找到了它需要的数据页同1:100。

  (3):发面页面1:100并不在内存中的数据缓存里。

  (4):sql server在缓冲池里找到一个可以存放的页面空间,在上面加EX的LATCH锁,防止数据从磁盘里读出来之前,别人也来读取或修改这个页面。

  (5):worker x发起一个异步i/o请求,要求从数据文件里读出页面1:100。

  (6):由于是异步i/o(可以理解为一个task子线程),worker x可以接着做它下面要做的事情,就是读出内存中的页面1:100,读取的动作需要申请一个sh的latch。

  (7):由于worker x之前申请了一个EX的LATCH锁还没有释放,所以这个sh的latch将被阻塞住,worker x被自己阻塞住了,等待的资源就是PAGEIOLATCH_SH。

  最后当异步i/o结束后,系统会通知worker x,你要的数据已经写入内存了。接着EX的LATCH锁释放,worker x申请得到了sh的latch锁。

总结:首先说worker是一个执行单元,下面有多个task关联Worker上, task是运行的最小任务单元,可以这么理解worker产生了第一个x的task任务,再第5步发起一个异步i/o请求是第二个task任务。二个task属于一个worker,worker x被自己阻塞住了。 关于任务调度了解查看sql server 任务调度与CPU。

 2.2 具体分析

  通过上面了解到如果磁盘的速度不能满足sql server的需要,它就会成为一个瓶颈,通常PAGEIOLATCH_SH 从磁盘读数据到内存,如果内存不够大,当有内存压力时候它会释放掉缓存数据,数据页就不会在内存的数据缓存里,这样内存问题就导致了磁盘的瓶颈。PAGEIOLATCH_EX是写入数据,这一般是磁盘的写入速度明显跟不上,与内存没有直接关系。

下面是查询PAGEIOLATCH_x的资源等待时间:

select wait_type,
waiting_tasks_count,
wait_time_ms ,
max_wait_time_ms,
signal_wait_time_ms
from sys.dm_os_wait_stats
where wait_type like 'PAGEIOLATCH%' 
order by wait_type

下面是查询出来的等待信息:

PageIOLatch_SH 总等待时间是(7166603.0-15891)/1000.0/60.0=119.17分钟,平均耗时是(7166603.0-15891)/297813.0=24.01毫秒,最大等待时间是3159秒。

PageIOLatch_EX 总等待时间是(3002776.0-5727)/1000.0/60.0=49.95分钟,    平均耗时是(3002776.0-5727)/317143.0=9.45毫秒,最大等待时间是1915秒。

图片 11

关于I/O磁盘 sys.dm_io_virtual_file_stats 函数也做个参考

SELECT  
       MAX(io_stall_read_ms) AS read_ms,
         MAX(num_of_reads) AS read_count,
       MAX(io_stall_read_ms) / MAX(num_of_reads) AS 'Avg Read ms',
         MAX(io_stall_write_ms) AS write_ms,
        MAX(num_of_writes) AS write_count,
         MAX(io_stall_write_ms) /  MAX(num_of_writes) AS 'Avg Write ms'
FROM    sys.dm_io_virtual_file_stats(null, null)
WHERE   num_of_reads > 0 AND num_of_writes > 0 

图片 12

  总结:PageIOLatch_EX(写入)跟磁盘的写入速度有关系。PageIOLatch_SH(读取)跟内存中的数据缓存有关系。通过上面的sql统计查询,从等待的时间上看,并没有清晰的评估磁盘性能的标准,但可以做评估基准数据,定期重置,做性能分析。要确定磁盘的压力,还需要从windows系统性能监视器方面来分析。 关于内存原理查看”sql server 内存初探“磁盘查看"sql server I/O硬盘交互" 。

   CXPACKET是指:线程正在等待彼此完成并行处理。什么意思呢? 当sql server发现一条指令复杂时,会决定用多个线程并行来执行,由于某些并行线程已完成工作,在等待其它并行线程来同步,这种等待就叫CXPACKET。

  为什么会有并行线程呢?  因为在sql server 里有个任务调度SCHEDULER是跟操作系统CPU个数 默认是一 一匹配的,  我们也可能通过sp_configure来设置最大并行度,也就是Max Degree of Parallelism (MAXDOP)。 关于调度可参考" sql server 任务调度与CPU"

  并行处理的优势: 用多个线程来执行一个指令,当sql server发现一条指令复杂时或语句中含有大数据量要处理,此时执行计划会决定用多个线程并行来执行,从而提高整体响应时间,例如一个指令读入100w条记录, 如果用一个线程做 可能需要10秒, 如果10个线程来做 可能只需要1秒,加上线程间同步时间也不过2秒。

  并行处理的劣势:1是并行线程要等待同步。2是由于这10个线程全力以赴,就有10个对应的cpu,这样别的用户发过来的指令就会受到影响,甚至拿不到cpu来执行。所以对于并发度要求高的需要及时响应的,一般会建议手动设置每个指令的并行线程数。反之可以不设置Max Degree of Parallelism由系统默认去并行或者设少一点并行度。

   1.1   查询 CXPACKET的等待

  借助上一次性能调优的资源等待统计图,会发现等待时间最长的就是CXPACKET类型。

  图片 13

 1.2  模拟CXPACKET的并行处理