我们一起聊聊 SQLServer 的Latch

我们一起聊聊 SQLServer 的Latch

昨天聊了下SQLSERVER的spinlock，当时我认为spinlock是与*** LATCH相对应的结构，事实上碎片化的阅读会带来一些知识掌握的不准确。***的LATCH是通过spin来实现锁的获取的，spin是LATCH获取轻量级锁的一种方式。而在SQLSERVER中，LATCH和spinlock被设计成两种轻量级锁，分别用于不同的场景。***有shared pool，library cache等结构，可以用shared pool闩锁来保护整个共享池，共享池中新增的一些乱七八糟的数据结构可以通过shared pool闩锁以及mutex来实现串行化访问保护。

SQLSERVER中并无此类机制，因此对于一些重度访问的内存结构，设计了LATCH来保护，而其他的一些数据结构，使用spinlock。在SQLSERVER中，总是使用spinlock来保护那些访问十分快速的内存结构。

LATCH是 *** 的SQL引擎用来保证内存结构的一致性的轻量级原子操作用来保护索引、数据页和内部结构等结构，例如 B 树中的非叶页。LATCH仅存在于SQL引擎内部。*** 使用缓冲LATCH来保护缓冲池中的页面，并使用 I/O LATCH来保护尚未加载到缓冲池中的页面。每当向 *** 缓冲池中的页面写入或读取数据时，工作线程必须首先获取该页面的缓冲LATCH。有多种缓冲LATCH类型可用于访问缓冲池中的页面，包括独占LATCH (PAGELATCH_EX) 和共享LATCH(PAGELATCH_SH)。

当 ***访问一个尚未加载到缓冲池中的页面时，将通过一个异步 I/O操作将该页面加载到缓冲池中。如果 *** 需要等待 I/O 子系统响应，它将根据请求类型等待独占 (PAGEIOLATCH_EX) 或共享 (PAGEIOLATCH_SH) I/O LATCH；这样做是为了防止另一个工作线程使用不兼容的LATCH将同一页面加载到缓冲池中。LATCH还用于保护对缓冲池页面以外的内部存储器结构的访问；这些被称为非缓冲LATCH。

PAGELATCH的争用在多 CPU 系统十分常见。当多个线程同时尝试获取相同内存结构的不兼容LATCH时，就会发生LATCH争用。闩锁是一种内部并发控制机制，SQL 引擎会自动确定何时使用它们。因为闩锁的行为是确定性的，数据库SCHEMA的设计，表、索引等的设计会影响闩锁争用。

非缓存页的闩锁名称为LATCH_XX，其中“_XX”后缀表示了闩锁的模式（PAGEIOLATCH/PAGELATCH也使用后缀表示模式）。*** 的闩锁模式可以总结如下：

lKP——保持LATCH，确保引用的结构不会被破坏。当线程想要查看缓冲区结构时使用。因为 KP LATCH兼容除销毁（DT）之外的所有LATCH，因此 KP 闩锁被认为是“轻量级”的，这意味着使用它时对性能的影响最小。由于 KP 闩锁与 DT 闩锁不兼容，它会阻止任何其他线程破坏引用的结构。KP 闩锁将防止它引用的结构被lazywriter 进程破坏（脏块写盘并释放缓冲）；

lSH -- 共享闩锁，需要读取引用的结构（例如读取数据页）。多个线程可以同时访问共享闩锁下的资源以进行读取。

lUP——更新闩锁，与 SH（共享闩锁）和 KP 兼容，但不兼容其他闩锁，因此不允许 EX 闩锁写入引用的结构。

lEX——独占闩锁，阻止其他线程写入或读取引用的结构。一个使用示例是修改页面内容以保护页面损坏。

lDT -- 销毁闩锁，必须在销毁引用结构的内容之前获取。例如，lazywriter 进程必须获取一个 DT 闩锁以释放一个干净的页面，然后再将其添加到可供其他线程使用的空闲缓冲区列表中。

上面的描述中关于闩锁兼容性的描述，可以用上表来表示。如果我们看到一个闩锁，可以通过”_”之后的后缀来区分其模式。比如PAGEIOLATCH_EX是一个独享的PAGEIOLATCH，LATCH_DT是一个非缓冲区保护的销毁闩锁。

和***的子闩锁类似，SQLSERVER也存在类似的结构，称为superlatch或者sublatch。目的是使用多个子闩锁来提高闩锁的并发性能。SQLSERVER使用多线程结构，并采用缓冲区动态扩展的方式。因此superlatch机制与NUMA架构做了一些优化，使之更好的适应NUMA。

SuperLatches 可以提高访问共享页面的性能，其中多个并发运行的工作线程需要 SH 闩锁。为此，*** 引擎会将此类页面上的闩锁动态提升为 SuperLatch。

在为大型服务器设计的高吞吐量系统上，必定会出现高并发的闩锁争用，在此类系统中存在闩锁争用是十分正常的现象。但是当闩锁争用和闩锁等待类型等待时间大到足以降低 CPU 利用率的情况下，系统的整体吞吐量会严重下降。识别和识别闩锁争用的迹象很重要，所以让我们必须有能力来分析这种情况。*** 闩锁的预期行为（与每秒事务数相关）是每秒事务数将随着平均 *** 闩锁等待时间的增加而增加，其本身以缓慢的速度增加。如果数据库并发增长的趋势与闩锁等待的趋势十分接近，那么闩锁争用并没有产生额外的负面影响。如果闩锁等待幅度远远超过数据库负载的增长，那么就说明闩锁出现了严重的争用。这个判断原则在大多数情况下是有效的。

我已经比较长时间没有仔细阅读数据库厂商官方的白皮书了，通过这两天的学习，我学到了一个分析数据的方法。实际上有些指标之间是存在较为同步的关联关系的，通过上升或者下降的幅度（可以通过统计学方法计算出一个可评估的度量）之间的对比，可以发现一些系统的性能问题。以前我们做了一个指标关联性分析工具，用于发现数据库某个指标异常可能存在的问题。实际上用这种更为简单的算法，也可以发现系统中存在的一些背离预期行为的场景，并用于告警。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。