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

Question

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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

Answer 3

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

Answer 4

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_latch_stats:

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