SQL Server PageIOLatch和PageLatch

Latch是轻量级的锁,它是SQL Server内部用来同步资源访问的一个数据结构,使数据的访问同步有序,这意味着,当一个线程获得资源R的Latch的独占使用权时,如果其他的线程也想访问这个Latch时,那么它必须等待该Latch的独占使用权释放。

一,Latch介绍

Latch主要分为两种:Buffer Latch,I/O Latch,分别用于保护内存中的数据页和硬盘上的数据页。Latch的类型受到Buffer的一个比特的控制,bit:BUF_IO,该比特位表示Latch当前是否在做buffer的IO操作。当SQL Server从硬盘中读取一个Page时,会在Buffer Pool中预留一个Buffer(内存中的Page),并且为该Buffer的比特BUF_IO 设为1。如果Page从硬盘中读取,写入到Cache中,那么该bit设置为0。当BUF_IO=1时,对该Page申请的Latch是PageIOLatch;当BUF_IO=0时,对该Page申请的Latch是PageLatch。

我们先来简短介绍一下I/O Latch。当SQL Server从硬盘上读取一个页时,会先在内存预留该页的空间。并且在该预留空间的某一个位BUF_IO设为1。如果数据从硬盘读写完成,则该位设为0. 从硬盘读取页的期间,其他也需要访问该页的线程当然要等待,等待类型为PAGEIOLATCH_SH,直到读写完成,BUF_IO被设为0为止。另外一种Latch则称为Buffer Latch,用来保护内存里的数据结构,当进程需要读取一个内存里的数据页时,该进程要先获取该数据页上的Buffer Latch。

1,PageIOLatch

如果数据页不存在于Buffer Pool中,SQL Server必须从硬盘中把数据加载到内存,此时,SQL Server需要在Buffer Pool中预留一个Buffer,并为该Buffer申请一个PageIOLatch_EX,表示正在把数据页(Data Page)或索引叶(Index Page)加载到内存;如果数据页已经加载到内存,那么 PageIOLatch_EX 释放。在从硬盘读取到缓存的期间,需要访问该数据页的所有线程都需要等待,等待类型是:PageIOLatch_SH,如果我们看到大量PAGEIOLATCH_SH等待,则基本可以断定问题是出在磁盘性能上面。

PageIOLatch_EX 和 PageIOLatch_SH是不兼容的,直到Disk的读取过程完成,PageIOLatch_EX释放,线程申请到PageIOLatch_SH,表示数据页已经存在于Buffer Pool中。如果Disk IO缓慢,一个会话(Session)可能会对同一个Page同时申请PageIOLatch_EX 和 PageIOLatch_SH,自己把自己阻塞(block),毕竟请求数据写入的目的,就是为了读取数据。

SQL Server 从硬盘读取一个Page的过程如下:

  1. Acquires an EX latch on the page that does not exist in the buffer pool (EX mode: blocking others, and no duplicate same IO will be issued)  数据页不在内存中,SQL server 申请并得到该页的EX独占类型的latch。
  2. Issues the I/O request to read the page from disk  发出I/O请求,将该Page从Disk读取到Buffer pool。
  3. Tries to acquire another latch that has the shared (SH) latch mode on the same page. Because an EX latch has already been acquired, the SH latch request is blocked, and the SPID is suspended, so temporarily it seems the same SPID was blocking itself  试图在该页上面获得另外一个共享类型latch。因为该页的latch EX已经获得,而EX和SH不兼容,所以SH必须等待。看起来就像自己等待自己。
  4. When the I/O request finishes, the EX latch on the page is released 当页读取完毕,EX latch释放。
  5. Release of the EX latch gives the SH latch to the same thread 因为Latch EX 释放,Latch SH就成功获得。
  6. The thread can now read the page 现在该线程成功获得latch SH,可以读取该页了(该页已经在内存里面了)。

2,PageLatch

在访问数据库的数据页(Data Page或Index Page)时,如果相应的buffer已经存在于Buffer Pool中,那么SQL Server先获取buffer的latch,这个Latch就是 PageLatch,然后读取Buffer中的数据。

PageLatch是Buffer Latch, 用来保护内存中的数据结构,当进程需要读取一个内存里的数据页时,该进程要先获取该数据页上的Buffer Latch。

3,PageLatch和PageIOLatch都是加在内存page上的Latch

如果要读取数据库某一个数据页中的数据,那么这个数据页必须存在于内存中。如果不存在于内存中,SQL Server 发出一个IO请求,将该Page加载到内存中,然后从内存中读取该数据页中的数据。在数据读取的过程中,SQL Server创建Latch结构使该过程顺利进行。在访问一个Data Page之前,必须首先获取该page的Latch。如果Page不在内存中,获取的是PageIOLatch;如果page存在于内存中,获取的是PageLatch。

PageIOLatch_XX:当数据页不在内存里时,SQL Server 先在内存中预留一个Page,然后从Disk读取,加载到内存Page,此时,SQL Server申请并获取的latch类型是PAGEIOLATCH,PageIOLatch表示正在进行IO操作。PageIOLatch_EX表示正在将disk中的数据页加载到内存,PageIOLatch_SH表示在加载数据页到内存期间,试图读取内存中的数据页,此时加载数据页的过程没有完成,处于loading状态。如果经常出现PageIOLatch_SH,表明Loading数据页的时间太长,可能出现IO bottleneck。

PageLatch_XX:数据页已经存在于内存中,对内存数据页加的latch是PageLatch。此时从disk加载数据页的operation已经完成,处于Loaded状态,一个数据库page同时存在于内存和disk,在访问内存页之前,添加的latch,就是PageLatch。

----读后感 Buffer Latch Timeout的解析

IO Latch表示SQL Server正在将disk中的数据页加载到buffer Pool,一旦数据页加载完成,IO Latch就会释放。在加载数据页到buffer pool时,SQL Server Engine先在内存中预留一个page的空间,将位BUF_IO设置为1。内存中的Page,叫做Buffer。当BUF_IO=1时,对该Page加的Latch是PageIOLatch。当数据加载完成,该Page的位BUF_IO设置为0。当BUF_IO设置为0时,对该Page加的Latch是PageLatch。IO Latch和Buffer Latch都是对内存中的Page加的Latch,只不过,IOLatch是在Data Loading期间,BUF_IO位为1时,加在内存page上的latch;Buffer Latch是Data 加载完成, BUF_IO为0时,加在内存page上的latch。

当SQL Server从硬盘上读取一个页时,会先在内存预留该页的空间,并且将该预留空间的位BUF_IO设为1。如果数据从硬盘读写完成,则该位设为0。从硬盘读取页的期间,其他也需要访问该页的线程当然要等待,等待类型为PAGEIOLATCH_SH,直到读写完成,BUF_IO被设为0为止。因此,如果我们看到大量PAGEIOLATCH_SH等待,则基本可以断定问题是出在磁盘性能上面。

二,Latch和性能

1,数据的IO操作

SQL Server访问的任何一个Page必须存在于内存中,如果不存在于内存中,那么SQL Server发出 Disk IO请求,将数据页从Disk读取到内存中,然后SQL Server从内存中读取该Page的内容。在访问任何一个内存page之前,必须申请和获取该Page上的Latch。

在数据读取的过程中,SQL Server先在内存中预留一个Page的空间,并设置该Page的位BUF_IO=1,并发出Disk IO请求,此时,在该Page上加的Latch是PageIOLatch_EX,表示正在将数据页从Disk读取到内存。

在数据页加载的过程中,任何一个读取该Page的Thread,在该Page上加的Latch是PAGEIOLATCH_SH,表示在SQL Server Engine从Disk读取数据页,写入内存时,Thread试图读取该Page,由于PAGEIOLATCH_SH和PageIOLatch_EX不兼容,读取该Page的Thread会被Block,直到Page被读取到内存中。

一旦数据页被写入到内存中,PageIOLatch_EX会立即释放,并设置该Page的位BUF_IO=0。由于数据页存在于内存中,对该Page申请的Latch是PageLatch。

如果发生PAGEIOLATCH类型的等待,那么SQL Server一定是在等待Disk I/O操作的完成。如果经常出现这类等待,说明磁盘速度不能满足要求,已经成为SQL Server的瓶颈。PAGEIOLATCH_XX主要分为两大类:PAGEIOLATCH_SH和PAGEIOLATCH_EX。

PAGEIOLATCH_SH 发生在用户访问一个数据页,同时SQL Server正在将数据页从磁盘写入内存,经常发生PAGEIOLATCH_SH等待,说明内存不够大,导致SQL Server需要做很多页面读取的操作,磁盘IO是内存压力的副作用。

PAGEIOLATCH_EX:发生在从Disk page读取到内存buffer中,经常发生PAGEIOLATCH_EX等待,说明Disk读取速度慢,这和内存没直接关系。

2,数据页成为HotPage

当一个Task要修改页面时,它必须先申请一个EX的Latch,即PageLatch_EX。只有获取到Latch,才能修改页面的内容。由于数据页的修改都是在内存中完成,所以时间应该非常短,可以忽略不计。而PAGELATCH_EX只是在修改过程中才出现,所以生存周期应该很短,如果出现了,说明:1、SQL Server没有明显的内存和磁盘瓶颈。2、应用程序发出大量的并发语句修改同一张表,而修改操作集中在同一个页面,或者数量不多的几个页面上,成为Hot Page。3、这种瓶颈无法通过提高硬件配置解决,只能修改 Table的存储,使修改分散在更多的Page上,提高并发修改的能力。

Hot page的缓解方法:

(1)、换一个数据列建聚集索引,而不要在Identity字段上,同一时间插入有机会分散到不同的页面上。

(2)、如果一定要在Identity的字段上建聚集索引,建议在其他某个列上创建若干个分区。

(3)、为FileGroup增加File,尽量将Files分布在不同的Physical Disk上。

3,在tempdb中,系统Page成为Hot Page

SQL Server不仅在数据页面上加Latch,而且在数据文件的系统页面上,例如SGAM、PFS和GAM页面等,也会加Latch。系统Page有时候也会成为系统瓶颈。

在创建新表时,SQL Server 需要分配空间。分配存储空间需要同时修改SGAM、PFS和GAM页面,设置标识位,由于一个系统Page的标志位管理很多数据页,当频繁的创建和删除表结构时,而这些数据页都发生在同一个系统Page,或者数量不多的几个系统Page上,会使该系统Page过热,成为Hot Page。在tempdb中,创建和删除table结构的操作会并发、反复发生,容易使系统页过热,产生hot Page。系统page过热,可以通过调整表设计来缓解。对此的解决方法:

  • 建立与cpu数量相同的tempdb文件,保持File Size相同,使得每个File承担的IO压力相对平均
  • 禁止 tempdb 文件自动增长,避免单个文件不平均增长

引用《Q&A on Latches in the SQL Server Engine》:

Anytime you talk about latching and database pages, think in terms of BUF (buffer) latches. So to read a page from disk and put this into cache, the worker thread will take out a EX (Exclusive) latch on the BUF associated with the page. Then the read is issues for the page. Then a SH latch is taken out by this same thread on this BUF structure. Since these are not compatible, the thread will wait. Makes sense since we need to wait for the page to be read in from disk before trying to look at it. Any other thread needing to read this page will also wait since you need a SH latch on a BUF to read the page in cache. When the read has completed, the EX latch is released, and now the SH latch is acquired and the thread(s) can read the page in cache.

When a thread has to wait on a BUF latch, the engine will look at the BUF structure to see if a special bit is turned on called BUF_IO. This is set when a page associated with the BUF is currently being read from or written to disk. This is how the engine knows that if your thread is waiting on a latch, that it is waiting on an “IO Latch”. The wait_type will therefore look something like PAGEIOLATCH_SH as opposed to PAGELATCH_SH.

A latch is a short-term lightweight synchronization object. The following list describes the different types of latches:

  • Non-buffer (Non-BUF) latch: The non-buffer latches provide synchronization services to in-memory data structures or provide re-entrancy protection for concurrency-sensitive code lines. These latches can be used for a variety of things, but they are not used to synchronize access to buffer pages.
  • Buffer (BUF) latch: The buffer latches are used to synchronize access to BUF structures and their associated database pages. The typical buffer latching occurs during operations that require serialization on a buffer page, (during a page split or during the allocation of a new page, for example). These latches are not held for the duration of a transaction. These are indicated in the master.dbo.sysprocesses table by the PAGELATCH waittypes.
  • IO latch: The IO latches are a subset of BUF latches that are used when the buffer and associated data page or the index page is in the middle of an IO operation. PAGEIOLATCH waittypes are used for disk-to-memory transfers and a significant waittime for these waittypes suggests disk I/O subsystem issues.

参考文档:

Buffer Latch Timeout的解析

什么是PAGELATCH和PAGEIOLATCH

Q&A on Latches in the SQL Server Engine….

原文地址:https://www.cnblogs.com/littlewrong/p/9240170.html

时间: 2024-07-31 23:44:09

SQL Server PageIOLatch和PageLatch的相关文章

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

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

SQL Server 性能调优(一)——从等待状态判断系统资源瓶颈

原文:SQL Server 性能调优(一)--从等待状态判断系统资源瓶颈 通过DMV查看当时SQL SERVER所有任务的状态(sleeping.runnable或running) 2005.2008提供了以下三个视图工详细查询: DMV 用处 Sys.dm_exec_requests 返回有关在SQL Server中执行的每个请求的信息,包括当前的等待状态 Sys.dm_exec_sessions 对于每个通过身份验证的会话都返回相应的一行.此时图是服务器范围的视图.此视图首先可以查到服务器负

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

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

Performance Monitor4:监控SQL Server的IO性能

SQL Server的IO性能受到物理Disk的IO延迟和SQL Server内部执行的IO操作的影响.在监控Disk性能时,最主要的度量值(metric)是IO延迟,IO延迟是指从Application创建IO请求,到Disk完成IO请求的时间延迟.如果物理Disk不能及时完成IO请求,跟不上请求负载的速度,那么SQL Server就容易出现性能问题.SQL Server内部在执行一些特定的操作时,会和Disk做读写交互,这也会影响物理硬盘响应SQL Server的IO请求的性能,使查询进程处

[转]The SQL Server Wait Type Repository

原文:http://blogs.msdn.com/b/psssql/archive/2009/11/03/the-sql-server-wait-type-repository.aspx As part of my talk at the 2009 US PASS Summit here in Seattle called Inside SQL Server Wait Types, I’m creating this blog post as a reference point that can

SQL Server 2008 基础

SQL流程 TDS是一种协议,一系列描述两个计算机间如何传输数据的规则.象别的协议一样,它定义了传输信息的类型和他们传输的顺序.总之,协议描述了"线上的位",即数据如何流动.表格数据流协议是建立在TCP/IP Net-Library之上的,包含在TCP数据段内.TDS用1433端口进行数据库通信. TDS协议位于TCP的数据段内,结构如下: IP TCP TDS头 TDS的DATA段 8位头 TDS客户端使用称为表格格式数据流 (TDS) 的 SQL Server 专用应用程序级协议来

SQL Server I/O 问题的诊断分

一. SQL Server 什么时候和磁盘打交道: 1. SQL 需要访问的数据没有在Buffer pool中,第一次访问时需要将数据所在的页面从数据文件中读取到内存中.(只读) 2. 在insert/update/delete提交之前, 需要将日志记录缓存区写入到磁盘的日志文件中.(写) 3. Checkpoint的时候,需要将Buffer pool中已经发生修改的脏数据页面同步到磁盘的数据文件中.(写) 4. 当Buffer pool空间不足的时候, 会触发Lazy writer, 主动将内

如何识别SQL Server中的IO瓶颈

原文:如何识别SQL Server中的IO瓶颈 原文出自: http://www.mssqltips.com/sqlservertip/2329/how-to-identify-io-bottlenecks-in-ms-sql-server/ 问题: 我们可能经常会遇到SQLServer数据库频繁关闭的情况.在分析了内存和CPU使用情况后,我们需要继续调查根源是否在I/O.我们应该如何识别SQLServer是否有I/O相关的瓶颈? 解决: 当数据页经常从缓冲池中移进移出的时候,I/O子系统就会成

SQL Server 2008性能故障排查(三)——I/O

原文:SQL Server 2008性能故障排查(三)--I/O 接着上一章:CPU瓶颈 I/O瓶颈(I/O Bottlenecks): SQLServer的性能严重依赖I/O子系统.除非你的数据库完全加载到物理内存中,否则SQLServer会不断地把数据库文件从缓存池中搬进搬出,这会引起大量的I/O传输.同样地,日志记录在事务被声明为已提交前必须写入磁盘.最后,SQLServer基于许多原因使用tempdb,比如存储临时结果.排序和保持行版本.所以一个好的I/O子系统是SQLServer性能关