Database
 sql >> база данни >  >> RDS >> Database

Как стартират паралелните планове – част 5

Това е последната част от серия от пет части, която се потапя дълбоко в начина, по който започват да се изпълняват паралелните планове в режим на ред на SQL Server. Част 1 инициализира нулев контекст на изпълнение за родителската задача, а част 2 създаде дървото за сканиране на заявка. Част 3 стартира сканирането на заявката, изпълни някаква ранна фаза обработка и стартира първите допълнителни паралелни задачи в клон C. Част 4 описва синхронизацията на обмена и стартирането на паралелни планови клонове C &D.

Старт на паралелни задачи на клон B

Напомняне за клоновете в този паралелен план (щракнете за уголемяване):

Това е четвъртият етап в последователността на изпълнение:

  1. Клон А (родителска задача).
  2. Клон C (допълнителни паралелни задачи).
  3. Клон D (допълнителни паралелни задачи).
  4. Клон Б (допълнителни паралелни задачи).

Единствената активна нишка в момента (не е спряна на CXPACKET). ) е родителската задача , който е от страната на потребителя на обмена на потоци за преразпределение на възел 11 в клон Б:

Родителската задача вече се връща от вложени ранни фази повиквания, настройка на изминали и процесорни времена в профайлърите, докато върви. Първото и последното активно време сане актуализиран по време на обработка в ранна фаза. Не забравяйте, че тези числа се записват спрямо нулев контекст на изпълнение — паралелните задачи на клон B все още не съществуват.

Родителската задача изкачва се дървото от възел 11, през агрегата на потока в възел 10 и обединението за сливане в възел 3, обратно към обмена на събиране на потоци във възел 2.

Обработката на ранната фаза вече е завършена .

С оригиналния EarlyPhases обаждане на възел 2събиране на потоци обмен най-накрая завършена, родителската задача се връща към отварянето на този обмен (може да си спомните това обаждане отдясно в началото на тази серия). Отвореният метод на възел 2 сега извиква CQScanExchangeNew::StartAllProducers за създаване на паралелни задачи за клон Б.

Родителската задача сега чака на CXPACKET припотребитела страна на възела 2събиране на потоци обмен. Това изчакване ще продължи, докато новосъздадените задачи на клон B не завършат вложените си Open обаждания и се връща към завършване на отварянето от страна на производителя на обмена на събиране на потоци.

Отворени паралелни задачи на клон B

Двете нови паралелни задачи в клон Б започват отпроизводитела страна на възела 2събиране на потоци обмен. Следвайки обичайния итерационен модел на изпълнение в редовия режим, те извикват:

  • CQScanXProducerNew::Open (възел 2 от страната на производителя е отворен).
  • CQScanProfileNew::Open (профильор за възел 3).
  • CQScanMergeJoinNew::Open (сливане на възел 3).
  • CQScanProfileNew::Open (профильор за възел 4).
  • CQScanStreamAggregateNew::Open (агрегат на поток от възел 4).
  • CQScanProfileNew::Open (профильор за възел 5).
  • CQScanExchangeNew::Open (обмен на потоци за преразпределение).

И двете паралелни задачи следват външния (горен) вход към обединението за сливане, точно както направи ранната фазова обработка.

Завършване на обмена

Когато задачите на клон Б пристигат при потребителя страна на обмен на потоци за преразпределение на възел 5, всяка задача:

  • Регистрира се с порта за обмен (CXPort ).
  • Създава тръбите (CXPipe ), които свързват тази задача с една или повече странични задачи на производителя (в зависимост от типа обмен). Текущият обмен е преразпределение на потоци, така че всяка потребителска задача има две тръби (при DOP 2). Всеки потребител може да получи редове от всеки от двата производителя.
  • Добавя CXPipeMerge засливане редове от множество канали (тъй като това е обмен за запазване на реда).
  • Създава редови пакети (с объркващо име CXPacket ) се използва за контрол на потока и за буфериране на редове през обменните тръби. Те се разпределят от предварително предоставена памет за заявки.

След като и двете паралелни задачи от страна на потребителя завършат тази работа, обменът на възел 5 е готов за работа. Двамата потребители (в клон B) и двамата производители (в клон C) са отворили обменния порт, така че възел 5 CXPACKET изчаква края .

Контролен пункт

Както стоят нещата:

  • Родителската задача в Клон А чака на CXPACKET от страната на потребителя на възел 2 събират обмен на потоци. Това изчакване ще продължи, докато и двамата производители на възел 2 се върнат и не отворят борсата.
  • Двете паралелни задачи в Клон Б са изпълними . Те току-що отвориха потребителската страна на обмена на потоци за преразпределение на възел 5.
  • Двете паралелни задачи в Клон C току-що бяха освободени от техния CXPACKET изчакайте и сега са изпълними . Двата агрегата на потока на възел 6 (по един на паралелна задача) могат да започнат да агрегират редове от двата сорта на възел 7. Припомнете си, че търсенето на индекс на възел 9 е затворено преди известно време, когато сортирането завърши своята фаза на въвеждане.
  • Двете паралелни задачи в Клон D чакат на CXPACKET от страна на производителя на обменните потоци за преразпределение на възел 11. Те ​​чакат потребителската страна на възел 11 да бъде отворена от двете паралелни задачи в клон B. Търсенето на индекса е затворено и сортовете са готови да преминат към тяхната изходна фаза.

Множество активни клона

Това е първият път, когато имаме няколко клона (B и C) активни едновременно, което може да бъде предизвикателство за обсъждане. За щастие дизайнът на демонстрационната заявка е такъв, че агрегатите на потока в клон C ще произведат само няколко реда. Малкият брой тесни изходни редове лесно ще се поберат в буферите на пакетите за редове на възела 5 преразпределение на потоци обмен. Следователно задачите на клон C могат да продължат с работата си (и в крайна сметка да се затворят), без да чакат потоците за преразпределение на възел 5 от страна на потребителя, за да извлече каквито и да било редове.

Удобно, това означава, че можем да оставим двете паралелни задачи на клон C да работят във фонов режим, без да се притесняваме за тях. Трябва само да се занимаваме с това, което правят двете паралелни задачи на клон B.

Отварянето на клон Б завършва

Напомняне за клон B:

Двата паралелни работници в клон B се връщат от своя Open извиквания в възела 5 обмен на потоци за преразпределение. Това ги връща обратно през агрегата на потока на възел 4, към обединяването за сливане на възел 3.

Защото ние се изкачваме дървото в Open метод, профилиращите програми над възел 5 и възел 4 записват последно активен време, както и натрупване на изминало и процесорно време (на задача). Сега не изпълняваме ранни фази на родителската задача, така че числата, записани за нулев контекст на изпълнение, не са засегнати.

При обединяването на сливането двете паралелни задачи на клон B започват надолу вътрешният (по-нисък) вход, превеждайки ги през агрегата на потока на възел 10 (и няколко профайлъра) към потребителската страна на обмена на потоци за преразпределение на възел 11.

Клон D възобновява изпълнението

Повторение на събитията от клон C в възел 5 сега се случва в потоците за преразпределяне на възел 11. Потребителската страна на обмена на възел 11 е завършена и отворена. Двамата производители в клон D прекратяват своя CXPACKET чака, става изпълним отново. Ще оставим задачите на клон D да работят във фонов режим, поставяйки резултатите им в буфери за обмен.

Вече има шест паралелни задачи (по двама в клонове B, C и D) съвместно споделяне на времето на двата планировчика, присвоени на допълнителни паралелни задачи в тази заявка.

Откриването на клон А завършва

Двете паралелни задачи в клон B се връщат от своя Open извиквания в възел 11 за преразпределяне на потоци обмен, нагоре покрай агрегата на потока на възел 10, през обединението за сливане на възел 3 и обратно към страната на производителя на събиращите потоци на възел 2. Profiler последно активен и натрупаните изминали и процесорни времена се актуализират, докато се изкачваме по дървото във вложен Open методи.

Припроизводитела от страната на обмена на събраните потоци, двете паралелни задачи на клон B се синхронизират, отваряйки порта за обмен, след което изчакайте CXPACKET за отваряне от страна на потребителя.

Родителската задача чакането от страна на потребителя на събирателните потоци вече е освободено от неговия CXPACKET чакане, което му позволява да завърши отварянето на обменния порт от страна на потребителя. Това от своя страна освобождава производителите от техния (кратък) CXPACKET изчакайте. Възелът 2 за събиране на потоци вече е отворен от всички собственици.

Завършване на сканирането на заявката

Родителската задача сега се издига на дървото за сканиране на заявки от обмена на събиране на потоци, връщайки се от Open разговори на борсата, сегменти , ипроект за последователност оператори в клон А.

Това завършва отварянето дървото за сканиране на заявки, инициирано преди всичко от извикването на CQueryScan::StartupQuery . Всички клонове на паралелния план вече са започнали да се изпълняват.

Връщане на редове

Планът за изпълнение е готов да започне да връща редове в отговор на GetRow извиквания в корена от дървото за сканиране на заявки, инициирано от извикване на CQueryScan::GetRow . Няма да навлизам в пълни подробности, тъй като това е строго извън обхвата на статия за това как започват паралелни планове .

Все пак кратката последователност е:

  • Родителската задача извиква GetRow на проекта за последователност, който извиква GetRow на сегмента, който извиква GetRow на потребителя страна на обмена на събирателни потоци.
  • Ако все още няма налични редове на борсата, основната задача изчаква на CXCONSUMER .
  • Междувременно, независимо изпълняващите се паралелни задачи на клон B рекурсивно извикват GetRow като се започне от производитела страна на обмена на събирателни потоци.
  • Редове се подават на клон B от страна на потребителите на обмените на потоци за преразпределение на възли 5 и 12.
  • Клонове C и D все още обработват редове от техните сортове чрез съответните им агрегати на потока. Задачите от клон Б може да се наложи да изчакат на CXCONSUMER при преразпределяне на потоци възли 5 и 12, за да стане достъпен пълен пакет от редове.
  • Редове, излизащи от вложения GetRow повикванията в клон B се събират в пакети от ред в производителя страна на обмена на събирателни потоци.
  • CXCONSUMER на родителската задача изчакайте от страната на потребителя на събирането на потоци, когато пакетът стане наличен.
  • След това ред по ред се обработва чрез родителските оператори в клон А и накрая към клиента.
  • В крайна сметка редовете се изчерпват и вложено Close колът се движи надолу по дървото, през борсите и паралелното изпълнение приключва.

Резюме и заключителни бележки

Първо, обобщение на последователността на изпълнение на този конкретен план за паралелно изпълнение:

  1. Родителската задача отваря клон А . Ранна фаза обработката започва при обмен на събиране на потоци.
  2. Извикванията на началната фаза на родителската задача спускат дървото за сканиране към търсенето на индекс на възел 9, след което се изкачват обратно към обмена за преразпределяне на възел 5.
  3. Родителската задача стартира паралелни задачи за Клон C , след което изчаква, докато прочетат всички налични редове в операторите за блокиране на сортиране на възел 7.
  4. Повикванията в ранна фаза се издигат до обединението за сливане, след което се спускат вътрешния вход към обмена на възел 11.
  5. Задачи за Клон D се стартират точно както за клон C, докато родителската задача изчаква на възел 11.
  6. Повикванията в ранна фаза се връщат от възел 11 до потоците за събиране. Ранната фазасвършва тук.
  7. Родителската задача създава паралелни задачи за Клон B , и изчаква, докато отварянето на клон B приключи.
  8. Задачите от клон B достигат до потоците за преразпределяне на възел 5, синхронизират се, завършват обмена и освобождават задачите от клон C, за да започнат да агрегират редове от сортирането.
  9. Когато задачите на клон B достигнат до потоците за преразпределяне на възел 12, те се синхронизират, завършват обмена и освобождават задачите от клон D, за да започнат да агрегират редове от сортирането.
  10. Задачите от клон B се връщат към обмена на събирателни потоци и се синхронизират, освобождавайки родителската задача от нейното изчакване. Родителската задача вече е готова да започне процеса на връщане на редове на клиента.

Може да искате да гледате изпълнението на този план в Sentry One Plan Explorer. Уверете се, че сте активирали опцията „С профил на заявка на живо“ за колекция от действителен план. Хубавото при изпълнението на заявката директно в Plan Explorer е, че ще можете да преминете през множество заснемания със собствено темпо и дори да превъртите назад. Той също така ще покаже графично обобщение на I/O, CPU и изчаквания, синхронизирани с данните за профилиране на заявка на живо.

Допълнителни бележки

Възходящото дърво за сканиране на заявка по време на обработка в ранна фаза задава първото и последното активно време за всеки профилиращ итератор за родителската задача, но не натрупва изминало или процесорно време. Изкачване на дървото по време на Open и GetRow извикванията на паралелна задача задава последното активно време и натрупват изминало и процесорно време за всеки профилиращ итератор за задача.

Ранната фазова обработка е специфична за паралелните планове в редовия режим. Необходимо е да се гарантира, че обмените са инициализирани в правилния ред и всички паралелни машини работят правилно.

Родителската задача не винаги изпълнява цялата обработка в ранна фаза. Ранните фази започват от root обмен, но как тези извиквания се движат в дървото зависи от срещаните итератори. Избрах обединяване за сливане за тази демонстрация, защото се случва да изисква обработка на ранна фаза и за двата входа.

Ранните фази при (например) паралелно хеш присъединяване се разпространяват само надолу по входа за изграждане. Когато хеш присъединяването премине към своята фаза на проверка, то се отваря итератори на този вход, включително всякакви обмени. Започва се друг кръг от обработка в ранна фаза, обработвана от (точно) една от паралелните задачи, играеща ролята на родителската задача.

Когато обработката в ранна фаза срещне паралелен клон, съдържащ блокиращ итератор, той стартира допълнителните паралелни задачи за този клон и изчаква тези производители да завършат своята фаза на отваряне. Този клон може също да има дъщерни клонове, които се обработват по същия начин, рекурсивно.

Някои клонове в паралелен план в редов режим може да се наложи да се изпълняват в една нишка (например поради глобален агрегат или връх). Тези „серийни зони“ също работят върху допълнителна „паралелна“ задача, като единствената разлика е, че има само една задача, контекст на изпълнение и работник за този клон. Ранната фазова обработка работи еднакво независимо от броя на задачите, възложени на клон. Например, „серийна зона“ отчита времето за родителската задача (или паралелна задача, която играе тази роля), както и за отделната допълнителна задача. Това се проявява в showplan като данни за „нишка 0“ (ранни фази), както и „нишка 1“ (допълнителната задача).

Заключителни мисли

Всичко това със сигурност представлява допълнителен слой сложност. Възвръщаемостта на тази инвестиция е в използването на ресурси по време на изпълнение (предимно нишки и памет), намалено изчакване на синхронизация, повишена пропускателна способност, потенциално точни показатели за производителност и минимизиран шанс от паралелни блокирания в рамките на заявката.

Въпреки че паралелизмът на редовия режим до голяма степен е засенчен от по-модерния механизъм за паралелно изпълнение на пакетен режим, дизайнът на редовия режим все още има известна красота. Повечето итератори могат да се преструват, че все още работят в сериен план, като почти цялата синхронизация, контрол на потока и планиране се обработват от борсите. Грижите и вниманието, които са очевидни в детайлите на внедряването, като обработка на ранна фаза, позволяват дори най-големите паралелни планове да се изпълнят успешно, без дизайнерът на заявки да обръща твърде много внимание на практическите трудности.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Изненади и предположения при представянето:произволен ТОП 1

  2. Разбиране на транзакциите в SQL

  3. Стартирането на базата данни на RAC се проваля с грешка ORA-12547

  4. PL/SQL Силен референтен курсор с дефиниран от потребителя тип данни на запис

  5. Моделът на данни за интелигентен дом