През последните 18 месеца се фокусирах върху реакциите на коляното за изчакване на статистически анализ и други теми, свързани с настройката на производителността, и в тази публикация ще продължа това и ще обсъдя PAGELATCH_XX чака. XX в края на изчакването означава, че има няколко типа PAGELATCH изчакайте, а най-често срещаните примери са:
- PAGELATCH_SH – ( SH са) чакат за достъп до страница с файл с данни в паметта, за да може да се прочете съдържанието на страницата
- PAGELATCH_EX или PAGELATCH_UP – (EX включващ или ГОРЕ дата) чака достъп до страница с файл с данни в паметта, за да може съдържанието на страницата да бъде променено
Когато един от тези видове чакане е най-разпространен на сървъра, реакцията на коляното е, че проблемът е нещо общо с I/O (т.е. объркване с PAGEIOLATCH_XX чакане, който разгледах в публикация през 2014 г.) и някой се опитва да добави повече памет или да настрои I/O подсистемата. Нито една от тези реакции няма да има никакъв ефект, тъй като спорните страници на файлове с данни вече са в паметта в буферния пул!
Във всички случаи можете да видите дали имате проблем с PAGELATCH_XX спор с помощта на sys.dm_os_waiting_tasks скрипт в моя блог или с помощта на инструмент като Performance Advisor, както е показано (за различен тип чакане) в тази публикация.
И така, какъв е източникът на спора? Първо ще обясня фона на тези видове чакане, а след това ще обсъдя двете най-често срещани причини за PAGELATCH_XX спор.
Фон:ключалки
Преди да разгледам някои от причините за PAGELATCH_XX чака, искам да обясня защо изобщо съществуват.
Във всяка многонишкова система структурите от данни, които могат да бъдат достъпни и манипулирани от множество нишки, трябва да бъдат защитени, за да се предотвратят сценарии като:
- Две нишки актуализират структура от данни едновременно и някои от актуализациите са загубени
- Нишка, актуализираща структура от данни едновременно с друга нишка, която чете структурата от данни, така че нишката за четене вижда смесица от стари и нови данни
Това е основна компютърна наука и SQL Server не се различава, така че всички структури от данни в SQL Server трябва да имат многонишков контрол на достъпа.
Един от механизмите, които SQL Server използва, за да направи това, се нарича фиксатор, при който задържането на ключалката в изключителен режим не позволява на други нишки да имат достъп до структурата на данните, а задържането на ключалката в режим на споделяне не позволява на други нишки да променят структурата на данните. SQL Server също използва заключване за някои структури от данни и ги обсъдих в тази публикация през 2014 г.
Но защо страницата с файл с данни в паметта е защитена от ключалка, може да се чудите? Е, страницата с файл с данни е просто структура от данни, макар и със специално предназначение, и затова се нуждае от същите контроли за достъп като всяка друга структура от данни. Така че, когато една нишка трябва да промени страница с файл с данни, тя трябва да придобие ексклузивно или актуализиращо ключалка на страницата, а ако не може и трябва да изчака, типът на чакане PAGELATCH_EX или PAGELATCH_UP резултати.
Класическо tempdb Contention
PAGELATCH Конфликтът в tempdb обикновено е върху растерни карти за разпределение и се случва при натоварвания с много едновременни връзки, създаващи и изпускащи малки временни таблици (които се съхраняват в tempdb).
Когато първият ред се вмъкне във временна таблица, трябва да бъдат разпределени две страници (страница с данни и страница IAM, която проследява страницата с данни). Тези страници трябва да бъдат маркирани като разпределени в специална страница за разпределение, наречена страница PFS, и по подразбиране се разпределят от специални екстенти на данни, които се проследяват от друга страница за разпределение, наречена страница SGAM (подробности за тях можете да намерите в моята стара публикация в блога тук). Когато временната таблица отпадне, тези страници трябва да бъдат освободени отново, което налага повече промени в PFS и SGAM страниците.
Ако временните таблици са малки и кумулативният размер на всички едновременно създадени временни таблици е по-малък от 64MB, тогава всички тези промени в растерната карта на разпределението са центрирани върху първите PFS и SGAM страници във файла с данни tempdb (с ID на страница (1:1) и (1:3) съответно). Актуализирането на една от тези страници за разпределение изисква блокиране на страницата и само една нишка в даден момент може да променя страницата, така че всички останали нишки трябва да изчакат – с тип на изчакване PAGELATCH_UP .
От SQL Server 2005 нататък временните таблици могат да се кешират при изпускане, стига да са по-малки от 8MB (и в SQL Server 2014 не се създават в съхранена процедура, която също има DDL изрази във временната таблица). Това означава, че следващата нишка, която изпълнява същия план за заявка, може да извади временната таблица от кеша и да не се налага да се занимава с първоначалните разпределения. Това намалява споровете относно растерните карти за разпределение, но временният кеш на таблицата не е много голям, така че работните натоварвания със стотици едновременни създаване/изпускане на временни таблици все още ще водят до много спорове.
Тривиално е да се предотврати спорът на SGAM страниците в tempdb, като се активира документиран флаг за проследяване 1118 на сървъра, който според мен трябва да бъде активиран на всички сървъри по света и всъщност е непроменимото поведение по подразбиране в SQL Server 2016.
Предотвратяването на спорове на PFS страниците в tempdb е малко по-трудно. Ако приемем, че временните таблици са необходими за производителност, трикът е да имате множество файлове с данни за tempdb, така че разпределенията да се извършват кръгово между файловете, конкуренцията е разделена на множество PFS страници и така общото противоречие намалява. Няма правилен отговор за това колко файлове с данни трябва да имате, за съжаление. Можете да прочетете повече за общоприетите насоки за това в статия 2154845 на KB и в тази публикация в блога.
Вмъкване на гореща точка
В потребителските бази данни, честа причина за голям брой PAGELATCH_EX чака е гореща точка за вмъкване.
Това може да се случи, когато дадена таблица има клъстериран индекс с ключ за клъстер тип int или bigint и размер на ред, който е достатъчно малък, така че много десетки или повече реда на таблицата могат да се поберат на страница с данни на ниво лист на клъстерирания индекс.
За такава таблица, ако работното натоварване включва много десетки или стотици едновременни нишки, които се вмъкват в таблицата, много от нишките ще генерират редове със стойности за идентичност (и следователно ключове на клъстер), които трябва да бъдат вмъкнати в една и съща страница с данни на ниво лист .
Сега не забравяйте, че извършването на каквато и да е промяна на страница с файл с данни в паметта изисква изключително ключалка, така че всяка от нишките, които се опитват да вмъкнат в същата страница, трябва да придобие изключително ключалката на страницата. Докато всяка нишка държи изключителния ключ, другите нишки ще чакат PAGELATCH_EX за тази страница, превръщайки по същество едновременните вмъквания в синхронен процес с изключително тесни места.
Има няколко възможни решения за този проблем:
- Използвайте по-произволен ключ и признайте, че това ще доведе до фрагментация на индекса, така че използвайте и фактор за запълване на индекса, за да предотвратите разделянето на страници
- Разпръснете вложките в таблицата, като използвате някакъв механизъм за изкуствено разделяне
- Използвайте по-дълъг размер на ред в таблицата (това очевидно е най-неприятната опция)
Виждал съм, че се появява гореща точка за вмъкване като тази, когато някой се е опитал да премахне проблемите с фрагментацията на индекса, като промени произволен GUID клъстерен ключ на клъстерен ключ за int или bigint идентичност, но не успя да тества новата схема на таблицата при производствени натоварвания.
Резюме
Точно както при други типове изчакване, разбиране какво точно PAGELATCH_XX Средното чакане е ключово за разбирането как да ги отстраните.
Що се отнася до общата статистика за чакане, можете да намерите повече информация за използването им за отстраняване на неизправности в производителността в:
- Моята серия от публикации в блога на SQLskills, започваща със статистически данни за чакане или моля, кажете ми къде боли
- Моята библиотека за типове чакане и класове на заключване тук
- Моят онлайн курс за обучение на Pluralsight SQL Server:Отстраняване на проблеми с производителността с помощта на статистика за чакане
- Съветник за производителност на SQL Sentry
До следващия път, щастливо отстраняване на неизправности!
