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

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

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

Ответ 1

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

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

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

Ответ 2

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

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

Блокировка этого значения по умолчанию от 0 до 4 немедленно отключает высокую защелку на некоторых запросах.

Наша защелка запускала 1000 мс + до 30 000 мс в некоторых случаях.

Ответ 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'

Ответ 4

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