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

Posted 2020-12-03 mrhsr

一.概念

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

　　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

　　通过上面的查询就能找到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　

　　用来同步访问数据库PAGE的latch就是PAGELATCH了。SQL server的Buffpool里每个数据库页（8kb的PAGE）都有一个对应的LATCH。 要访问某个PAGE必须首先获得这个PAGE的LATCH。
　　当查询的数据页如果在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被自己阻塞住了，等待的latch是PAGEIOLATCH_SH. 为什么会自己等待自己呢？ 这个得从SQL server读取页的过程说起。SQL server从磁盘读取一个page的过程如下：

　　(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上运行的最小任务单元，可以是这么理解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

    通过上面的sql 查询，可以定期清空数据做统计的数据分析，当发现有异常时，要结全业务来分析内存与磁盘。关于内存查看”sql server 内存初探“磁盘查看"sql server I/O硬盘交互" 后面后从windows系统性能监视器方面来分析。