В предишната си публикация обсъдих LCK_M_XX, ASYNC_NETWORK_IO и OLEDB чаканията и реакциите на коляното към тях. В тази публикация ще продължа с темата за статистиката за чакане и ще обсъдя SOS_SCHEDULER_YIELD чакането.
Когато SOS_SCHEDULER_YIELD е най-разпространеният на сървър, е обичайно да се наблюдава продължително високо използване на процесора. Реакцията на коляното тук е, че сървърът трябва да е под натиск на процесора или че проблемът е блокирането на въртене.
Имаме нужда от малко предистория, за да разберем тези две реакции.
Планиране на нишки
Планирането на нишки в SQL Server се управлява от самия SQL Server, а не от Windows (т.е. не е изпреварващо). Частта на SQL OS на Storage Engine осигурява функционалност за планиране и преход на нишки от изпълнение на процесор (където състоянието на нишката е ИЗПЪЛНЯВА) към това да бъде в списъка на чакащите, чакайки ресурсът да стане достъпен (състоянието е ПРЕКРАСНО) към това да бъде в Runnable Подредете се на опашка, след като ресурсът стане наличен (състоянието е ИЗПЪЛНЯЕМО), изчаквайки да стигнете до върха на опашката и отново да се върнете към процесора (обратно в състояние ИЗПЪЛНЯВА). Изписах с главни букви процесор, списък на сервитьори и опашка за изпълнение, за да ги идентифицирам като части от планировчик.
Всеки път, когато дадена нишка се нуждае от ресурс, който не може да придобие незабавно, тя се спира и изчаква в списъка на сервитьори, за да бъде уведомена (сигнализирана), че ресурсът й е наличен. Времето, прекарано в списъка с сервитьори, е времето за изчакване на ресурса, а времето, прекарано в опашката за изпълнение, е времето за изчакване на сигнала. Заедно те се комбинират, за да представляват общото време за изчакване. SQL OS следи времето за изчакване и времето за изчакване на сигнала, така че трябва да направим малко математика на изхода от sys.dm_os_wait_stats, за да извлечем времето за изчакване на ресурса (вижте моя скрипт тук).
Списъкът с сервитьорите е неподреден (всяка нишка в него може да бъде сигнализирана по всяко време и да се премести в опашката за изпълнение) и опашката за изпълнение е Първият-Първи-излязъл (FIFO) почти 100% от времето. Единственото изключение от Runnable Queue е FIFO, когато множество групи за натоварване на Resource Governor са конфигурирани в един и същ ресурсен пул и те имат различни приоритети един спрямо друг. Никога не съм виждал това да се използва успешно в производството, така че няма да го обсъждам допълнително.
Има и друга причина, поради която една нишка може да се наложи да се измести от процесора – тя изчерпва своя квант. Квантът на нишката в SQL OS е фиксиран на 4 милисекунди. Самата нишка е отговорна за определянето, че нейният квант е изчерпан (чрез извикване на помощни подпрограми в SQL OS) и доброволно отказване от процесора (известно като yielding). Когато това се случи, нишката се придвижва директно към дъното на опашката за изпълнение, тъй като няма какво да чака. Въпреки това SQL OS трябва да регистрира тип на изчакване за този преход извън процесора и да регистрира SOS_SCHEDULER_YIELD.
Това поведение често се бърка с натиска на процесора, но не е - това е просто продължително използване на процесора. Натискът на процесора и разпознаването му е съвсем друга тема за бъдеща публикация. Що се отнася до тази публикация, стига средното време за изчакване на сигнала да е ниско (0-0,1-0,2 мс), доста сигурно е, че налягането на процесора не е проблем.
Spinlocks
Заключването е примитив за синхронизация на много ниско ниво, който се използва за осигуряване на безопасен за нишки достъп до структури от данни в SQL Server, които са изключително горещи (много нестабилни и достъпни и променяни невероятно често от множество нишки). Примери за такива структури са списъкът с свободни буфери във всяка част от буферния пул и масивът за претегляне на пропорционално запълване за файловете с данни във файлова група.
Когато дадена нишка трябва да придобие spinlock, тя търси да види дали спинблокировката е свободна и ако е така, незабавно я придобива (използвайки взаимосвързан примитив на асемблер като „тестов бит изчистен и зададен“). Ако spinlockът не може да бъде получен, нишката незабавно се опитва да го придобие отново, и отново, и отново, за до хиляда итерации, докато не се оттегли (спи за малко). Това не се регистрира като тип на чакане, тъй като нишката просто извиква функцията на Windows sleep(), но може да накара други нишки, които чакат, да имат големи (10-20ms+) времена на изчакване на сигнала, тъй като спящата нишка остава на процесора, докато не получава въртене.
Защо говоря за spinlocks? Тъй като те също могат да бъдат причина за високо използване на процесора и има погрешно схващане, че спинлокациите са причина за изчакване на SOS_SCHEDULER_YIELD. Не са.
SOS_SCHEDULER_YIELD Причини
Така че има една причина за SOS_SCHEDULER_YIELD:нишка, изчерпваща своя квант за планиране и силно повтарящи се екземпляри, може да доведе до това, че SOS_SCHEDULER_YIELD е най-разпространеното чакане заедно с високото използване на процесора.
Няма да видите SOS_SCHEDULER_YIELD изчаквания да се показват в изхода от sys.dm_os_waiting_tasks, тъй като нишката не чака. Можете да видите коя заявка генерира изчакванията SOS_SCHEDULER_YIELD, като заявите sys.dm_exec_requests и филтрирате в колоната last_wait_type.
Това също означава, че когато видите SOS_SCHEDULER_YIELD в изхода на sys.dm_os_wait_stats, изчакването на ресурса ще бъде нула, защото всъщност не е чакало. Но не забравяйте, че всяко от тези „изчаквания“ се равнява на 4 мс време на процесора, натрупано за заявката.
Единственият начин да се докаже какво причинява изчакване на SOS_SCHEDULER_YIELD е да се заснемат стекове от извиквания на SQL Server, когато се появи този тип чакане, като се използват разширени събития и символи за отстраняване на грешки от Microsoft. Имам публикация в блога, която описва и показва как да се извърши това разследване, и има страхотен бял документ за spinlocks и spinlock разследвания, който си струва да прочетете, ако се интересувате от тази дълбочина на вътрешните елементи.
В случай на квантово изтощение, това не е основната причина. Това е допълнителен симптом. Сега трябва да помислим защо една нишка може да изчерпва своя квант многократно.
Една нишка може да изчерпи своя квант само когато може да продължи да обработва кода на SQL Server за 4 мс, без да се нуждае от ресурс, който притежава друга нишка – без чакане за ключалки, ключалки на страници, страници с файлове с данни да бъдат прочетени от диска, разпределения на памет, нарастване на файлове, регистриране , или безбройните други ресурси, от които една нишка може да се нуждае.
Най-често срещаната част от кода, при която може да възникне квантово изчерпване и да натрупа големи количества SOS_SCHEDULER_YIELD чакания, е сканиране на индекс/таблица, където всички необходими страници с файлове с данни са в паметта и няма спор за достъп до тези страници и ето какво Насърчавам ви да търсите в плановете за заявка, когато видите SOS_SCHEDULER_YIELD като най-добрия тип чакане – големи и/или повтарящи се сканирания на индекс/таблица.
Това не означава, че казвам, че големите сканирания са лоши, тъй като може да се окаже, че най-ефективният начин за обработка на вашето работно натоварване е чрез сканиране. Въпреки това, ако изчакванията SOS_SCHEDULER_YIELD са нови и необичайни и са причинени от големи сканирания, трябва да проучите защо плановете за заявка използват сканирания. Може би някой е изпуснал критичен неклъстериран индекс, или статистическите данни са остарели и така е избран неправилен план за заявка, или може би необичайна стойност на параметъра е била предадена на съхранена процедура и планът на заявката е извикан за сканиране или промяна на кода възникна без поддържащи индексни добавки.
Резюме
Точно както при другите типове изчакване, разбирането какво точно означава SOS_SCHEDULER_YIELD е от ключово значение за разбирането как да го отстраните и дали поведението се очаква поради натоварването, което се обработва.
Що се отнася до общата статистика за чакане, можете да намерите повече информация за използването им за отстраняване на неизправности в производителността в:
- Моята серия от публикации в блога на SQLskills, започваща със статистически данни за чакане или моля, кажете ми къде боли
- Моята библиотека за типове чакане и класове за заключване тук
- Моят онлайн курс за обучение на Pluralsight SQL Server:Отстраняване на проблеми с производителността с помощта на статистика за чакане
- Съветник за производителност на SQL Sentry
В следващата статия от поредицата ще обсъдя друг тип изчакване, който е често срещана причина за реакции на коляно. Дотогава, щастливо отстраняване на неизправности!
