Защелки SQL Server и их индикация проблем с производительностью

Question

Я пытаюсь понять потенциальную проблему с производительностью нашей базы данных (SQL 2008) и, в частности, одного счетчика производительности, SQLServer: Latches \ Total Latch Wait Time Общее время ожидания защелки (мс). Мы наблюдаем замедление времени отклика БД, и единственный коррелирующий всплеск, с которым я могу сопоставить его, - это всплеск общего времени ожидания защелки и ожиданий защелки в секунду. Я не вижу особых узких мест в дисковых операциях ввода-вывода, использовании процессора или памяти.

Распространенным объяснением защелки SQLServer является то, что это облегченная блокировка, но я пытаюсь получить более подробное понимание того, что такое защелка, чем она отличается от блокировки и каково их большое количество видение может быть индикатором для.

Answer 1

Возможно, это действительно основная ошибка для профессиональных администраторов баз данных ... но это то, что я обнаружил в нашей проблеме с высокой защелкой, и эта тема занимает очень высокое место в результатах поиска. Я подумала, что поделюсь своим мнением, что это может помочь кому-то еще.

на более новых двух / многопроцессорных серверах, использующих архитектуру памяти NUMA, максимальная степень параллелизма должна быть установлена ​​на фактическое число ядер на процессор. в нашем примере у нас был двойной ксенон с четырьмя ядрами в каждом, а с гиперпоточностью он выглядит как 16 логических процессоров для SQL.

Если заблокировать это значение по умолчанию от 0 до 4, сразу же отключается верхняя защелка для некоторых запросов.

В некоторых случаях наша защелка работала 1000 мс + до 30000 мс.

Answer 2

Я рекомендую вам ввести sys.dm_os_latch_stats и посмотреть, какие типы защелок имеют повышенные типы конкуренции и ожидания по сравнению с предыдущей базовой линией.

Если вы видите всплеск в защелках типа BUFFER, это означает, что он вызван обновлениями, конфликтующими для изменения той же страницы. Другие типы защелок также имеют краткое объяснение в MSDN и могут помочь вам найти причину проблемы. Для тех, кто помечен как «только для внутреннего использования», вам придется открыть службу поддержки с MS, поскольку подробное объяснение того, что они имеют в виду, находится на грани NDA.

Вам также следует заглянуть в sys.dm_os_wait_stats. Если вы видите увеличение PAGELATCH_*, то это та же проблема, что и у защелки типа BUFFER выше, конфликт при попытке изменить ту же страницу, иначе. как обновление горячей точки . Если вы видите увеличение PAGEIOLATCH_*, то ваша проблема связана с подсистемой ввода-вывода, поэтому загрузка страниц в память занимает слишком много времени, когда они необходимы.

Answer 3

Ссылка взята из этого блога:

Использование 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_latch_stats:

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

Answer 4

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