SQL Server闩锁及其性能问题指示

我建议你去看看 sys.dm_os_latch_stats 并查看与之前的基线相比,哪种类型的锁存增加了争用和等待类型。

如果在缓冲区类型闩锁中看到一个峰值,这意味着它是由与修改同一页相冲突的更新驱动的。其他闩锁类型在msdn中也有简短的解释,可以指导您找到问题的根本原因。对于那些标记为“仅供内部使用”的人,您必须与MS一起打开一个支持案例,详细解释它们的意思是什么,这就在NDA的边缘。

你也应该调查一下 sys.dm_os_wait_stats . 如果你看到 PAGELATCH_* 然后,它和上面的缓冲区类型锁存器是同一个问题,即试图修改同一页时的争用。作为一个 更新热点 .如果你看到增长 PAGEIOLATCH_* 那么,您的问题是I/O SusbyStem,当需要页面时,将它们加载到内存中需要太长时间。

这可能是专业DBA的一个基本错误…但这就是我发现的高锁存问题,这个线程在搜索结果中排名非常高。我想我会分享我们的一点,这样可以帮助别人。

在使用NUMA内存体系结构的新的双/多处理器服务器上,最大并行度应设置为每个处理器的实际内核数。在我们的示例中,我们有两个Xenon,每个Xenon有4个内核,在SQL中,它看起来像16个逻辑处理器。

将该值从默认值0锁定到4会立即关闭某些查询的高锁存。

在某些情况下,我们的闩锁可以运行1000毫秒以上,最多可以运行30000毫秒。

Reference taken from this blog:

使用sys.dm_db_index_operational_stats:

SELECT 
    OBJECT_NAME(object_id)
    ,page_latch_wait_count
    ,page_latch_wait_in_ms
    ,tree_page_latch_wait_count
    ,tree_page_latch_wait_in_ms  
    ,Page_io_latch_wait_count
    ,Page_io_latch_wait_in_ms
FROM sys.dm_db_index_operational_stats (DB_ID(), NULL, NULL, NULL)

使用sys.dm_os_lock_stats:

SELECT * FROM sys.dm_os_latch_stats  
WHERE latch_class = 'buffer'

sp_configure 'max degree of parallelism', 8
go
reconfigure
go