Още през 2014 г. започнах поредица от публикации в блога тук, за да говоря за конкретни видове чакане и какво правят и какво не означават. Това ми даде идеята да създам библиотеки за изчакване и заключване, които поддържам (повече за тях по-късно).
Ако четете това и си мислите „за какво говори той?“ тогава тази публикация е за вас. Ще ви представя да изчакате статистическите данни и да обясня колко критични са те за отстраняване на неизправности при производителността на работното натоварване в SQL Server.
График
Изпълнението на вътрешния код на SQL Server се извършва с помощта на механизъм, наречен нишки . Всяка нишка може да изпълнява код на SQL Server и множество нишки координират заедно, когато заявка се изпълнява паралелно. Тези нишки се създават при стартиране на SQL Server в зависимост от броя на процесорните ядра, налични за използване на SQL Server.
Нишките се поставят в планировчик когато заявка започне, с един планировщик на процесорно ядро и не премествайте този планировчик, докато заявката не приключи. Планировчикът има три основни „части“:
- процесор , който има точно една нишка, изпълняваща в момента код.
- Списъкът с сервитьори , който има всички нишки, които основно са блокирани, чакайки конкретен ресурс да стане достъпен.
- Опашката, която може да се изпълнява , който има всички нишки, които могат да се изпълняват, но чакат да влязат в процесора.
Нишките преминават от състояние 1 към 2 към 3 към 1, около и около, докато заявката приключи.
Чака
От наша гледна точка най-интересната част от планирането е, когато нишката трябва да изчака ресурс, преди да може да продължи. Някои примери за това са:
- Нишката трябва да прочете страница, а страницата не е в паметта, така че нишката издава асинхронен физически I/O и след това трябва да изчака извън процесора, докато I/O завърши.
- Една нишка трябва да придобие споделено заключване на ред, за да я прочете, но друга нишка вече има конфликтно изключително заключване, докато актуализира реда.
Когато дадена нишка срещне нужда от ресурс, който не може да получи, тя няма друг избор, освен да спре и да изчака ресурсът да стане достъпен (механизмът за това как нишката се уведомява за наличността на ресурса е извън обхвата на тази статия). Когато това се случи, SQL Server отбелязва защо нишката е трябвало да изчака и това се нарича тип чакане . Някои примери за това са:
- Когато дадена нишка чака страница да бъде прочетена в паметта, за да може да бъде прочетена, типът на изчакване е PAGEIOLATCH_SH (ако нишката чака страница, която ще промени, типът на изчакване е PAGEIOLATCH_EX ).
- Когато дадена нишка чака за заключване на споделяне на ред, типът на изчакване е LCK_M_S (заключен режим-споделяне)
SQL Server също така следи колко дълго трябва да чака нишката. Това се нарича време за изчакване на ресурс , и обикновено е известен просто като време за изчакване .
Статистика за изчакване
Общият набор от показатели за това колко нишки са чакали кои ресурси и за колко време средно се нарича статистика на чакането . Тази информация е изключително полезна за отстраняване на неизправности при производителността на работното натоварване, тъй като можете лесно да видите къде може да са тесни места в производителността.
Основната идея е, че SQL Server има информация защо нишките трябва да спират и да чакат и какво чакат. Така че вместо да се налага да гадаете откъде да започнете отстраняването на неизправности, внимателният анализ на статистическите данни за чакане обикновено може да ви насочи към посоката, в която да поемете.
Например, ако по-голямата част от чаканията на сървъра са PAGEIOLATCH_SH , това може да означава, че има натиск върху паметта върху сървъра или че има заявки, извършващи сканиране на големи таблици, вместо да използват неклъстерирани индекси, или че има проблем с основната I/O подсистема или редица други причини.
Има голям брой видове изчаквания, но повечето от тях не се появяват много често, така че има основен набор, който ще виждате отново и отново на вашите сървъри. Разбирането на това какво означават това и как да ги проучите е от решаващо значение, за да не се поддадете на това, което аз наричам „настройка на производителността на коляното“ и да губите време и усилия, опитвайки се да отстраните проблем, който всъщност не е проблем. Написах поредица от публикации в блога тук, които навлизат в подробности там, а Аарон Бертран също написа обобщена публикация за 10-те най-добри статистики за чакане миналата година.
Проследяването чака
Има редица начини, по които можете да проследявате чаканията. Най-простият е да погледнете какво чакане се случва на сървъра в момента, като използвате скрипт, който проверява sys.dm_os_waiting_tasks DMV. Можете да намерите скрипт за това тук и който има автоматично генерирани URL адреси в библиотеката за изчакване.
Друг начин е да разгледате обобщената статистика за чакане за целия сървър със скрипт, който проверява sys.dm_os_wait_stats DMV. Можете да намерите скрипт за това тук и който има автоматично генерирани URL адреси в библиотеката за чакане. Трябва обаче да внимавате с този метод, тъй като това ще покаже всички изчаквания, които са се случили от стартирането на сървъра. По-добър начин е да проследявате изчаквания на малки интервали, да речем половин час, и скрипт за това е тук.
Можете също да получите статистически данни за изчакване, като използвате добавката Server Reports към новия инструмент Azure Data Studio и като използвате Query Store от SQL Server 2017 нататък.
Не забравяйте, че все още трябва да разберете какво означават типовете чакане, след като съберете показателите.
Ресурси за изчакване
За да помогна с това и тъй като Microsoft няма документация за това как да интерпретира статистиката за изчакване, през 2016 г. пуснах библиотека с типове на чакане с подробности за стотици често срещани типове чакане и как да ги отстраня. Можете да стигнете до библиотеката на https://www.SQLskills.com/help/waits. И тогава през 2017 г. SentryOne създаде автоматизирана система, за да предостави инфографика за всяка страница в библиотеката, която можете бързо да използвате, за да видите дали типът на чакане, който ви интересува, е наистина често срещан или не (вижте тази публикация за подробности) . Примерна инфографика е по-долу за PAGEIOLATCH_SH тип чакане:
По хоризонталната ос е скала (с възможност за превключване между линейна и логаритмична) на какъв процент от случаите (наблюдавани дистанционно от SentryOne) са преживели това изчакване през предходния календарен месец, а по вертикалната ос е процентът от време, през който тези случаи са преживели това wait всъщност имаше нишка, която чака за този тип чакане.
Друг ресурс, който да ви помогне да разберете чаканията, е онлайн курс за обучение, който записах за Pluralsight – вижте тук.
Най-малкото трябва да прочетете различните публикации в блога в секциите „Статистика на чакането“ и „Проследяване на изчаквания“ по-горе.
Проследяване на изчакване с помощта на SentryOne Tools
SQL Sentry проследява автоматично изчакванията на ниво инстанция с течение на времето, така че не е нужно да хващате много чакащи „в действие“. Някой се е оплакал от бавна система вчера следобед или доклад, който изтече миналия вторник? Няма проблем. Можете да разгледате всички изчаквания за всеки момент от време или в диапазон и да ги съпоставите с различни други показатели за ефективност, събрани по това време – било то други тенденции на таблото за управление, като активност на архивиране или вход/изход на база данни, прескачане до всички най-добрите SQL команди, които са се изпълнявали в същия прозорец, разследват продължително блокиране или използват базови линии за сравняване на профила на изчакване с други периоди.
Можете дори да персонализирате изчаквания, които се събират или не се събират, да променяте категориите, които се представят визуално, и да изграждате интелигентни сигнали и/или отговори на конкретни сценарии на изчакване. Много от нашите клиенти използват SQL Sentry, за да се съсредоточат върху реални проблеми с производителността, свързани с изчакването, тъй като им позволява да игнорират голяма част от шума, който е просто нормална активност на нишките на SQL Server.
Резюме
Както можете да видите от информацията по-горе, изчакванията винаги се случват в SQL Server, защото точно така работят планирането на нишки и многонишковите системи. Те са един от най-мощните инструменти във вашата кутия с инструменти за отстраняване на неизправности, така че ако все още не ги използвате, сега е моментът да започнете. Кривата на обучение е кратка и стръмна – след като стартирате различните заявки и инструменти няколко пъти, бързо ще се овладеете, а след това е случай на четене през ръководствата за чаканията, които виждате и определяне дали са проблем или не.
Приятно отстраняване на неизправности!
