Zona de atenție specială – opțiunea Grad maxim de paralelism. Despre lucruri interesante din lumea IT, instrucțiuni și recenzii Sql grad maxim de paralelism

Optimizarea lucrului 1C. Configurarea serverului MS SQL

Activați inițializarea instantanee a fișierului bazei de date

• Crearea bazei de date
• Adăugați fișiere, jurnale sau date la o bază de date existentă
• Mărirea dimensiunii unui fișier existent (inclusiv operațiuni de creștere automată)
• Restaurarea unei baze de date sau a unui grup de fișiere

Pentru a activa setarea:

1. Pe computerul pe care va fi creat fișierul de rezervă, deschideți aplicația Local Security Policy (secpol.msc).
2. Extindeți nodul Politici locale din panoul din stânga, apoi faceți clic pe Atribuire drepturi de utilizator.
3. În panoul din dreapta, faceți dublu clic pe Efectuați activități de întreținere a volumului.
4. Faceți clic pe butonul „Adăugați” pentru un utilizator sau grup și adăugați aici utilizatorul sub care rulează MS SQL Server.
5. Faceți clic pe butonul Aplicați.

Activați opțiunea Blocare pagini în memorie

Această setare controlează ce conturi pot stoca date în RAM, astfel încât sistemul să nu trimită pagini de date către memoria virtuală de pe disc, ceea ce poate îmbunătăți performanța.

Pentru a activa setarea:

1. Din meniul Start, selectați Run. În câmpul Open, introduceți gpedit.msc.
2. În consola Local Group Policy Editor, extindeți Computer Configuration, apoi Windows Configuration.
3. Extindeți Setări de securitate și Politici locale.
4. Selectați folderul Atribuire drepturi utilizator.
5. Politicile vor fi afișate în panoul de detalii.
6. În acest panou, faceți dublu clic pe opțiunea Blocare pagini în memorie.
7. În caseta de dialog Opțiune de securitate locală - Blocare pagini de memorie, selectați Adăugați un utilizator sau un grup.
8. În caseta de dialog Selectați: utilizatori, conturi de serviciu sau grupuri, adăugați contul sub care rulați serviciul MS SQL Server.
9. Pentru ca modificările să aibă efect, reporniți serverul sau conectați-vă ca utilizator sub care rulați MS SQL Server.

Dezactivați DFSS pentru discuri.

Mecanismul Dynamic Fair Share Scheduling este responsabil pentru echilibrarea și distribuirea resurselor hardware între utilizatori. Uneori, funcționarea sa poate afecta negativ performanța 1C. Pentru a-l dezactiva numai pentru discuri, trebuie să:

1. Găsiți ramura HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TSFairShare\Disk în registru
2. Setați valoarea parametrului EnableFairShare la 0

Dezactivați compresia datelor pentru directoarele care conțin fișiere de bază de date.

Când compresia este activată, sistemul de operare va încerca să proceseze suplimentar fișierele în timpul modificării, ceea ce va încetini procesul de înregistrare în sine, dar va economisi spațiu.

Pentru a dezactiva compresia fișierelor dintr-un director, trebuie să:

1. Deschideți proprietățile directorului
2. În fila General, faceți clic pe Altele
3. Debifați indicatorul „Comprimați” conținut pentru a economisi spațiu pe disc.

Setați parametrul Grad maxim de paralelism la 1.

Acest parametru determină în câte fire poate fi executată o cerere. Implicit, parametrul este 0, ceea ce înseamnă că serverul însuși selectează numărul de fire. Pentru bazele de date cu o încărcare tipică 1C, se recomandă setarea acestui parametru la 1, deoarece în cele mai multe cazuri, acest lucru va avea un efect pozitiv asupra performanței interogărilor.

Pentru a configura parametrul trebuie să:

1. Deschideți proprietățile serverului și selectați fila Avansat
2. Setați valoarea parametrului la unu.

Limitați dimensiunea maximă de memorie a MS SQL Server.

Memorie pentru MS SQL Server = Memorie pentru tot – Memorie pentru OS – Memorie pentru serverul 1C

De exemplu, serverul are 64 GB de RAM instalat, trebuie să înțelegeți câtă memorie să alocați serverului DBMS, astfel încât să fie suficientă pentru serverul 1C.

Pentru funcționarea normală a sistemului de operare, în majoritatea cazurilor 4 GB sunt mai mult decât suficienti, de obicei 2-3 GB.

Pentru a determina câtă memorie necesită un server 1C, trebuie să vă uitați la câtă memorie ocupă procesele unui cluster de servere la vârful zilei de lucru. Aceste procese sunt ragent, rmngr și rphost; aceste procese sunt discutate în detaliu în secțiunea dedicată clusterului de servere. Datele trebuie preluate exact în perioada de vârf de activitate, când în baza de date lucrează numărul maxim de utilizatori. După ce ați primit aceste date, trebuie să adăugați 1 GB la ele - în cazul în care începeți operațiuni „grele” în 1C.

Pentru a seta cantitatea maximă de memorie utilizată de MS SQL Server, trebuie să:

1. Lansați Management Studio și conectați-vă la serverul dorit
2. Deschideți proprietățile serverului și selectați fila Memorie
3. Specificați valoarea parametrului Maximum server memory size.

Activați indicatorul de prioritate Boost SQL Server.

Acest flag vă permite să creșteți prioritatea procesului MS SQL Server față de alte procese.

Este logic să activați marcajul numai dacă serverul 1C nu este instalat pe computerul cu serverul DBMS.

Pentru a seta steagul trebuie să:

1. Lansați Management Studio și conectați-vă la serverul dorit
2. Deschideți proprietățile serverului și selectați fila Procesoare
3. Activați indicatorul „Boost SQL Server priority” și faceți clic pe OK.

Setați dimensiunea de creștere automată a fișierelor bazei de date.

Autogrow vă permite să specificați cantitatea cu care dimensiunea fișierului bazei de date va fi mărită atunci când este plin. Dacă setați dimensiunea de extindere automată prea mică, atunci fișierul se va extinde prea des, ceea ce va dura timp. Este recomandat să setați valoarea de la 512 MB la 5 GB.

1. Lansați Management Studio și conectați-vă la serverul dorit
2. Opus fiecărui fișier din coloana Auto-creștere, puneți valoarea necesară

Această setare se va aplica numai bazei de date selectate. Dacă doriți ca această setare să se aplice tuturor bazelor de date, trebuie să efectuați aceiași pași pentru baza de date a serviciului model. După aceasta, toate bazele de date nou create vor avea aceleași setări ca și baza de date model.

Separați fișierele de date mdf și fișierele jurnal ldf pe diferite discuri fizice.

În acest caz, lucrul cu fișierele poate continua nu succesiv, ci aproape în paralel, ceea ce crește viteza operațiunilor de pe disc. Unitățile SSD sunt cele mai potrivite pentru aceste scopuri.

Pentru a transfera fișiere aveți nevoie de:

1. Lansați Management Studio și conectați-vă la serverul dorit
2. Deschideți proprietățile bazei de date dorite și selectați fila Fișiere
3. Amintiți-vă numele și locațiile fișierelor
4. Detașați baza de date selectând Sarcini – Detașare prin meniul contextual
5. Bifați caseta de selectare Ștergere conexiuni și faceți clic pe OK
6. Deschideți File Explorer și mutați fișierul de date și fișierul jurnal pe mediul dorit
7. În Management Studio, deschideți meniul contextual al serverului și selectați Atașați baza de date
8. Faceți clic pe butonul Adăugare și specificați fișierul mdf de pe noul disc
9. În fereastra de informații inferioară a bazei de date, în linia cu fișierul jurnal, trebuie să specificați noua cale către fișierul jurnal de tranzacții și să faceți clic pe OK.

Nu este un secret pentru nimeni că atunci când iau în considerare problemele de configurare a unui server SQL legate de creșterea productivității, majoritatea specialiștilor IT optează pentru creșterea hardware-ului. Dar este întotdeauna justificat acest lucru? Au fost deja folosite toate metodele de configurare a serverului? Se știe că lucrul cu parametrii de configurare și modificarea valorilor implicite ale acestora poate îmbunătăți performanța și alte caracteristici ale unui anumit sistem. Printre aceste opțiuni de configurare SQL, există o opțiune care are multe întrebări asociate, această opțiune este Grad maxim de paralelism (DOP) - așa că vom vorbi despre asta.

Opțiunea Maximum Degree of Parallelism (DOP) determină numărul de fire pe care SQL Server poate paraleliza o interogare și indică numărul de procesoare server utilizate. Acest parametru are o valoare implicită de 0 – gradul maxim de paralelism. De exemplu, dacă aveți 24 de nuclee, atunci valoarea „gradului maxim de paralelism” va fi egală cu 24, iar optimizatorul, dacă consideră necesar, poate folosi toate procesoarele pentru a executa o singură instrucțiune, adică cererea va fi paralelizate în 24 de fire. Acest lucru este bun pentru majoritatea cazurilor, dar nu pentru toată lumea. De asemenea, nu este întotdeauna bine să folosiți valoarea implicită a acestui parametru. Configurarea acestui parametru poate fi necesară, de exemplu, în următoarea situație: să presupunem că avem o aplicație în care toți angajații introduc informații despre tranzacțiile zilnice și, la o anumită perioadă de timp, fiecare dintre utilizatori rulează o interogare care construiește un raportează toate tranzacțiile utilizatorului pentru o anumită perioadă de timp. Desigur, dacă perioada de timp este lungă, această solicitare va dura mult timp pentru a se finaliza și, cu DOP instalat în mod implicit, va ocupa toate procesoarele disponibile, ceea ce va afecta în mod natural munca altor utilizatori. Prin urmare, prin modificarea valorii DOP, putem crește timpul de răspuns al serverului SQL pentru alți utilizatori fără a modifica interogarea în sine.
MS recomandă setarea valorii după cum urmează:

Setarea parametrului la TSQL în întregime pentru server:

EXEC sp_configure "gradul maxim de paralelism", 4; reconfigura

De asemenea, puteți seta această valoare pentru o anumită interogare TSQL:

UTILIZAȚI AdventureWorks2008R2; GO SELECT ProductID, OrderQty, SUM(LineTotal) AS TotalFROM Sales.SalesOrderDetail WHERE UnitPrice< $5.00 GROUP BY ProductID, OrderQty ORDER BY ProductID, OrderQty OPTION (MAXDOP 2); GO

În acest exemplu, indicația maxdop modifică valoarea implicită a parametrului gradul maxim de paralelism la 2. Puteți vizualiza setarea curentă astfel:

EXEC sp_configure "Show Advanced",1; RECONFIGURAȚI; EXEC sp_configure „gradul maxim de paralelism”

Acum să vedem cum această valoare afectează viteza de execuție a interogării. Pentru ca interogarea de test scrisă mai sus să fie executată mai mult timp, îi vom adăuga o altă selecție. Cererea va avea următoarea formă:

< $5.00) dt2 WHERE dt.UnitPrice < $5.00 GROUP BY dt.ProductID, dt.OrderQty ORDER BY dt.ProductID, dt.OrderQty

Pe mașina mea de testare, valoarea „gradului maxim de paralelism” este setată la 0. MSSQL rulează pe o mașină cu un procesor cu 4 nuclee. Am efectuat o serie de experimente cu diferite valori MAXDOP: egale cu 1 – fără paralelizare a interogărilor; egal cu 2 - folosind doar 2 nuclee; egal cu 4 – folosind toate și niciun indiciu pentru a determina opțiunea care utilizează continuarea implicită. Pentru a obține statistici de execuție, trebuie să includeți opțiunea SET STATISTICS TIME ON în interogare și, de asemenea, să activați butonul de afișare a planului de interogare în Management studio. Pentru a face o medie a rezultatelor, am rulat fiecare interogare într-o buclă de 3 ori. Rezultatele pot fi văzute mai jos:

SELECT dt.ProductID, dt.OrderQty, SUM(dt.LineTotal) AS Total FROM Sales.SalesOrderDetail dt, (SELECT * FROM Sales.SalesOrderDetail WHERE UnitPrice< $5.00) dt2 WHERE dt.UnitPrice < $5.00 GROUP BY dt.ProductID, dt.OrderQty ORDER BY dt.ProductID, dt.OrderQty OPTION (MAXDOP 1); SQL Server Execution Times: CPU time = 45942 ms, elapsed time = 46118 ms. SQL Server Execution Times: CPU time = 45926 ms, elapsed time = 46006 ms. SQL Server Execution Times: CPU time = 45506 ms, elapsed time = 45653 ms.

Planul de interogare arată că atunci când a fost instalat indiciu (MAXDOP 1), interogarea a fost executată fără paralelizare. Timp mediu de execuție a interogării 45925,66 ms

SELECT dt.ProductID, dt.OrderQty, SUM(dt.LineTotal) AS Total FROM Sales.SalesOrderDetail dt, (SELECT * FROM Sales.SalesOrderDetail WHERE UnitPrice< $5.00) dt2 WHERE dt.UnitPrice < $5.00 GROUP BY dt.ProductID, dt.OrderQty ORDER BY dt.ProductID, dt.OrderQty OPTION (MAXDOP 2); SQL Server Execution Times: CPU time = 51684 ms, elapsed time = 28983 ms. SQL Server Execution Times: CPU time = 51060 ms, elapsed time = 26165 ms. SQL Server Execution Times: CPU time = 50903 ms, elapsed time = 26015 ms.

La instalarea hint-ului (MAXDOP 2), cererea a fost executată în paralel pe 2 cpu, acest lucru se poate vedea în Numărul de execuție din planul de execuție a interogării. Timp mediu de execuție a interogării 27054,33 ms

SELECT dt.ProductID, dt.OrderQty, SUM(dt.LineTotal) AS Total FROM Sales.SalesOrderDetail dt, (SELECT * FROM Sales.SalesOrderDetail WHERE UnitPrice< $5.00) dt2 WHERE dt.UnitPrice < $5.00 GROUP BY dt.ProductID, dt.OrderQty ORDER BY dt.ProductID, dt.OrderQty OPTION (MAXDOP 4); SQL Server Execution Times: CPU time = 82275 ms, elapsed time = 23133 ms. SQL Server Execution Times: CPU time = 83788 ms, elapsed time = 23846 ms. SQL Server Execution Times: CPU time = 53571 ms, elapsed time = 27227 ms.

La instalarea hint-ului (MAXDOP 4), cererea a fost executată în paralel pe 4 cpu. Timp mediu de execuție a interogării 24735,33 ms

SELECT dt.ProductID, dt.OrderQty, SUM(dt.LineTotal) AS Total FROM Sales.SalesOrderDetail dt, (SELECT * FROM Sales.SalesOrderDetail WHERE UnitPrice< $5.00) dt2 WHERE dt.UnitPrice < $5.00 GROUP BY dt.ProductID, dt.OrderQty ORDER BY dt.ProductID, dt.OrderQty SQL Server Execution Times: CPU time = 85816 ms, elapsed time = 23190 ms. SQL Server Execution Times: CPU time = 85800 ms, elapsed time = 23307 ms. SQL Server Execution Times: CPU time = 58515 ms, elapsed time = 26575 ms.

cererea a fost executata in paralel, tot 4 cpu. Timp mediu de execuție a interogării 24357,33 ms

link-uri: http://support.microsoft.com/kb/2023536

În această scurtă notă, aș dori să vorbesc puțin despre complexitatea setărilor de paralelism în Microsoft SQL Server. Mulți dintre voi sunteți conștienți de opțiunea Max Degree od Parallelism, care este prezentă în SQL Server de foarte mult timp. În mod implicit, este setat la 0, ceea ce înseamnă că SQL Server însuși va alege gradul optim de paralelism, adică numărul de procesoare/thread-uri folosite pentru a executa o instrucțiune. Acum nu mă voi opri și discuta la ce valoare este mai bine să setați această opțiune - acesta este un subiect pentru o notă separată. Mă voi uita doar la modul în care valoarea acestei opțiuni afectează execuția interogărilor. De exemplu, în figura de mai jos, această opțiune este setată la 1, ceea ce înseamnă că planurile paralele pentru toate interogările sunt dezactivate în mod implicit.

Această opțiune este disponibilă și pentru vizualizare folosind următoarea comandă T-SQL:

Într-adevăr, orice plan de interogare va fi secvenţial în mod implicit. De exemplu:

Cu toate acestea, dezvoltatorul și orice utilizator au în continuare posibilitatea de a influența acest lucru folosind indicii. Pentru a face acest lucru, trebuie doar să specificați gradul de paralelism dorit și este generat planul de interogare dorit, de exemplu:

Și dacă ne uităm la această interogare prin vizualizarea sys.dm_exec_query_profiles, vom vedea că este de fapt executată în 10 fire.

Astfel, rămâne o gaură secretă în sistem pe care dezvoltatorii și utilizatorii o pot folosi pentru a „accelera” (aici am pus-o între ghilimele intenționat, deoarece un grad ridicat de paralelism nu duce întotdeauna la o scădere a timpului de execuție a interogărilor) lor. interogări prin creşterea gradului de paralelism . Dar, în acest fel, ei pot pur și simplu „ucide” serverul rulând multe solicitări paralele necontrolate în același timp. Ce putem face în privința asta? Aici ne vine în ajutor Resource Governor, un sistem foarte puternic și complet subestimat, care vă permite să distribuiți foarte flexibil resursele între diferite grupuri de utilizatori. Din nou, nu mă voi opri acum asupra modului în care funcționează și ce capacități are. Voi intra în detaliu despre modul în care setările sale limită de concurență îl afectează. Să aruncăm mai întâi o privire la setările implicite:

Din nou vedem că implicit opțiunea este setată la 0 și decizia privind alegerea gradului maxim este lăsată la SQL Server. Acum să vedem ce se întâmplă dacă schimb această valoare la 5. Atenție, sub nicio formă nu faceți astfel de setări pe un sistem real, deoarece Nici măcar nu am definit funcția de clasificare pentru Resource Governor și schimb grupul implicit. Dar pentru a testa și a înțelege cum funcționează totul în mod specific acum în exemplul meu, acest lucru este suficient. Așa că limitez gradul maxim de paralelism pentru toată lumea la 5 fire. Permiteți-mi să vă reamintesc că opțiunea Gradul maxim de paralelism, la care ne-am uitat mai devreme este încă setată la valoarea 1. Dacă ne uităm acum la planul de execuție al interogării noastre inițiale, atunci implicit va fi secvenţial, iar cu opţiunea maxdop 10 va fi paralelă. Dar, dacă rulăm un plan paralel, vom vedea ceva interesant.

Acum cererea noastră este executată în doar 5 fire, în ciuda faptului că opțiunea maxdop are valoarea 10. Și, dacă specificați opțiunea maxdop 4 pentru cerere, aceasta va fi executată în 4 fire (opțiunea din Resource Governor este setată la 5). În acest caz, indiciu maxdop mai puțin decât setarea Resource Governor, deci nu este impusă nicio limitare suplimentară. Nu voi mai da un exemplu în acest sens.

Astfel, Resource Governor este un instrument mai puternic care limitează de fapt gradul maxim de paralelism pentru interogări, iar acest grad poate fi setat diferit pentru diferite grupuri de utilizatori. În acest caz, opțiunea Gradul maxim de paralelism continuă să funcționeze și își aduce contribuția (sau confundă ușor administratorii, dezvoltatorii și utilizatorii atunci când lucrează împreună cu Resource Governor). În plus, opțiunile de setare a valorilor acestor 2 parametri sunt limitate doar de imaginația ta, dar este important să reții doar două lucruri: Gradul maxim de paralelismși indiciu maxdop pentru o cerere, afectează ce plan va fi generat, numărul maxim de fire de execuție care va fi posibil pentru această solicitare, iar Guvernatorul resurselor limitează și mai mult cererea de sus în timpul execuției.

Gradul maxim de paralelism (DOP) este o opțiune suplimentară de configurare SQL Server care a făcut obiectul multor întrebări și publicații. În această postare pe blog, autorul speră să ofere o oarecare claritate cu privire la ceea ce face această opțiune și cum ar trebui utilizată.
În primul rând, autorul ar dori să clarifice orice îndoială că opțiunea listată stabilește câte procesoare poate folosi SQL Server atunci când deservește mai multe conexiuni (sau utilizatori) - nu este așa! Dacă SQL Server are acces la patru procesoare inactive și este configurat să folosească toate cele patru procesoare, va folosi toate cele patru procesoare, indiferent de gradul maxim de paralelism.
Deci, ce face această opțiune? Această opțiune setează numărul maxim de procesoare pe care SQL Server le poate folosi pentru o singură interogare. Dacă o interogare către SQL Server trebuie să returneze o cantitate mare de date (multe înregistrări), uneori are sens să o paralelizezi, împărțind-o în mai multe interogări mici, fiecare dintre acestea va returna propriul subset de rânduri. Astfel, SQL Server poate folosi mai multe procesoare și, prin urmare, pe sistemele multiprocesor, un număr mare de înregistrări ale unei întregi interogări pot fi returnate mai rapid decât pe un sistem cu un singur procesor.
Există multe criterii care trebuie luate în considerare înainte ca SQL Server să invoce „Intra Query Parallelism” (împărțirea unei interogări în mai multe fire) și nu are rost să le detaliezi aici. Le puteți găsi în BOL căutând „Grad de paralelism”. Se spune că decizia de paralelizare se bazează pe disponibilitatea memoriei la procesor și, mai ales, pe disponibilitatea procesoarelor în sine.
Deci, de ce ar trebui să luăm în considerare utilizarea acestei opțiuni - pentru că lăsarea acesteia la valoarea implicită (SQL Server ia propriile decizii de paralelizare) poate avea uneori efecte nedorite. Aceste efecte arată cam așa:

Interogările paralele rulează mai lent.

Timpii de execuție a interogărilor pot deveni nedeterminiști, ceea ce poate enerva utilizatorii. Timpul de execuție se poate modifica deoarece:

Interogarea se poate paralela uneori, alteori nu.

O solicitare poate fi blocată printr-o solicitare paralelă dacă procesoarele au fost supraîncărcate anterior de lucru.

Înainte de a continua, autorul ar dori să sublinieze că nu este nevoie în mod special de a se scufunda în organizarea internă a paralelismului. Dacă sunteți interesat de acest lucru, puteți citi articolul „Parallel Query Processing” din Books on Line, care descrie aceste informații mai detaliat. Autorul consideră că există doar două lucruri importante de știut despre organizarea internă a concurenței:

Interogările paralele pot genera mai multe fire decât cele specificate în opțiunea „Grad maxim de paralelism”. DOP 4 poate genera mai mult de douăsprezece fire, patru pentru interogare și fire suplimentare utilizate pentru sortări, fluxuri, agregate și ansambluri etc.

Solicitările paralele pot determina SPID-uri diferite să aștepte cu tipul de așteptare CXPACKET sau 0X0200. Acesta poate fi folosit pentru a găsi acele SPID-uri care sunt într-o stare de așteptare în timpul operațiunilor paralele și au un waittype în sysproceses: CXPACKET. Pentru a ușura această sarcină, autorul sugerează utilizarea procedurii stocate disponibilă pe blogul său: track_waitstats.

Și așadar „Interogarea poate fi mai lentă când este paralelizată” de ce?

Dacă sistemul are un debit foarte scăzut al subsistemelor de disc, atunci când se analizează o solicitare, descompunerea acesteia poate dura mai mult decât fără paralelism.

Poate exista o distorsiune a datelor sau o blocare a intervalelor de date pentru procesor cauzată de un alt proces utilizat în paralel și lansat ulterior etc.

Dacă nu există un index pe predicat, rezultă o scanare a tabelului. Operațiunea paralelă în cadrul unei interogări poate ascunde faptul că interogarea s-ar fi finalizat mult mai repede cu un plan de execuție secvențial și indexul corect.

Din toate acestea, rezultă o recomandare de a verifica execuția cererii fără paralelism (DOP=1), aceasta va ajuta la identificarea eventualelor probleme.
Efectele paralelismului menționate mai sus ar trebui să vă facă în mod natural să credeți că mecanica internă a paralelizării interogărilor nu este potrivită pentru utilizare în aplicațiile OLTP. Acestea sunt aplicații pentru care modificarea timpilor de execuție a interogărilor poate fi enervantă pentru utilizatori și pentru care un server care deservește mulți utilizatori concurenți este puțin probabil să aleagă un plan de execuție paralelă din cauza profilului inerent al sarcinii de lucru a procesorului acestor aplicații.
Prin urmare, dacă veți folosi paralelismul, atunci cel mai probabil veți avea nevoie de el pentru sarcini de recuperare a datelor (depozit de date), suport decizional sau sisteme de raportare, unde nu există multe interogări, dar sunt destul de grele și sunt executate pe un sistem puternic. server cu o cantitate mare de RAM.memorie.
Dacă decideți să utilizați paralelismul, ce valoare ar trebui să setați pentru DOP? O bună practică pentru acest mecanism este că, dacă aveți 8 procesoare, setați DOP = 4 și aceasta va fi cel mai probabil setarea optimă. Cu toate acestea, nu există nicio garanție că va funcționa în acest fel. Singura modalitate de a fi sigur este să testați diferite valori pentru DOP. În plus, autorul a dorit să ofere sfatul său empiric să nu seteze niciodată acest număr la mai mult de jumătate din numărul de procesoare disponibile. Dacă autorul ar avea mai puțin de șase procesoare, ar seta DOP la 1, ceea ce pur și simplu dezactivează paralelizarea. El ar putea face o excepție dacă ar avea o bază de date care acceptă doar un singur proces utilizator (unele tehnologii de recuperare a datelor sau sarcini de raportare), caz în care, ca excepție, ar fi posibil să setați DOP la 0 (valoarea implicită), care permite SQL Server însuși să decidă dacă să paralelizeze o interogare.
Înainte de a termina articolul, autorul a ținut să vă avertizeze că crearea indexului paralel depinde de numărul pe care îl setați pentru DOP. Aceasta înseamnă că este posibil să doriți să-l modificați în timp ce indexurile sunt create sau recreate pentru a îmbunătăți performanța acestei operațiuni și, desigur, puteți utiliza indicația MAXDOP în interogare, care vă permite să suprascrieți valoarea setată în configurație și puteți să fie utilizat în timpul orelor de vârf.
În cele din urmă, interogarea dvs. poate încetini atunci când este paralelizată din cauza erorilor, așa că asigurați-vă că serverul dvs. are cel mai recent pachet de servicii instalat.

Parametrul „gradul maxim de paralelism” specifică numărul maxim de fire de execuție pe care SQL Server poate paraleliza o interogare. În mod implicit, acest parametru este zero, ceea ce înseamnă că este utilizat numărul de procesoare al serverului. De exemplu, dacă aveți 24 de nuclee, valoarea reală a „gradului maxim de paralelism” va fi 24, iar optimizatorul, dacă consideră necesar, poate paraleliza interogarea în 24 de fire. În general, acest lucru este bun, dar nu întotdeauna. De asemenea, nu este întotdeauna bine să folosiți valoarea implicită a acestui parametru.

Acum să vedem de ce nu este bine. Voi da un exemplu din practica mea. Există o interogare care, în teorie, ar trebui să folosească un anumit index și la început se întâmplă acest lucru. Se lansează o interogare care caută indexul și returnează datele necesare. Totul e bine. Apoi, pe măsură ce baza de date crește, în tabel sunt adăugate din ce în ce mai multe înregistrări, iar la un moment dat optimizatorul își dă seama că este posibil să execute interogarea mai rapid: „De ce ar trebui să efectuez o căutare pe index dacă am 24 de nuclee? Aceasta înseamnă că pot scana indexul grupat în 24 de fire și pot obține datele de care am nevoie mai repede!” Pentru această interogare anume, acest lucru este bun - rulează mai repede. Dar este rău pentru toți ceilalți, pentru că... sunt nevoiți să aștepte ca resursele procesorului să le fie alocate. Și în sistemele cu un număr mare de interogări care se execută simultan, o astfel de paralelizare este mai probabil să fie proastă decât bună. Și în loc să îmbunătățească productivitatea, aceasta se înrăutățește doar. Până de curând, am rezolvat această problemă setând indicația MAXDOP în depozitele care nu mi-au plăcut. Dar acum am găsit o recomandare Microsoft specifică și am aplicat-o pe serverele mele. Recomandări pentru alegerea valorii optime pentru „gradul maxim de paralelism” sunt aici:Recomandări și orientări pentru opțiunea de configurare „gradul maxim de paralelism”. . Citez aceasta recomandare:

Pentru serverele SQL Server 2008 R2, SQL Server 2008 și SQL Server 2005, utilizați următorul ghid: a. Pentru serverele care au opt sau mai puține procesoare, utilizați următoarea configurație în care N este egal cu numărul de procesoare: gradul maxim de paralelism = 0 la N. b. Pentru serverele care folosesc mai mult de opt procesoare, utilizați următoarea configurație: grad maxim de paralelism = 8. c. Pentru serverele care au configurat NUMA, gradul maxim de paralelism nu trebuie să depășească numărul de procesoare care sunt atribuite fiecărui nod NUMA cu valoarea maximă limitată la 8. Acest lucru va crește probabilitatea ca toate firele paralele ale unei interogări să fie localizate într-un NUMA Node și evitați căutările costisitoare de date ale nodurilor de la distanță. d. Pentru serverele care au activat hyper-threading, valoarea maximă a gradului de paralelism nu trebuie să depășească numărul de procesoare fizice.

Rezultă că pentru sistemele cu mai mult de 8 procesoare, se recomandă setarea „gradului maxim de paralelism” = 8. Urmează o altă explicație, care precizează că 8 este o recomandare generală. Și în sistemele în care numărul de solicitări care se execută simultan este mic, este logic să setați o valoare mai mare, iar în sistemele cu un număr mare de solicitări concurente, este logic să setați o valoare mai mică. Și atunci când alegeți un anumit parametru, trebuie să vă uitați la impactul acestuia asupra sistemului și să-l testați pe anumite solicitări.