Om interessante ting fra IT-verdenen, instruksjoner og anmeldelser. Maks grad av parallellitet – velge optimal verdi Stille inn maksimal grad av parallellitet parameter

Optimalisering av 1C arbeid. Sette opp MS SQL server

Aktiver umiddelbar initialisering av databaser

Database opprettelse
Legg til filer, logger eller data til en eksisterende database
Øke størrelsen på en eksisterende fil (inkludert automatisk vekstoperasjoner)
Gjenopprette en database eller filgruppe

Slik aktiverer du innstillingen:

Åpne applikasjonen Local Security Policy (secpol.msc) på datamaskinen der sikkerhetskopifilen skal opprettes.
Utvid noden Lokale retningslinjer i venstre rute, og klikk deretter Tildel brukerrettigheter.
Dobbeltklikk på Utfør volumvedlikeholdsoppgaver i høyre rute.
Klikk på "Legg til"-knappen for en bruker eller gruppe og legg til brukeren som MS SQL Server kjører under her.
Klikk på Bruk-knappen.

Aktiver alternativet Lås sider i minnet

Denne innstillingen kontrollerer hvilke kontoer som kan lagre data i RAM, slik at systemet ikke sender sider med data til virtuelt minne på disken, noe som kan forbedre ytelsen.

Slik aktiverer du innstillingen:

Velg Kjør fra Start-menyen. I Åpne-feltet skriver du inn gpedit.msc.
I konsollen for redigering av lokal gruppepolicy utvider du Computer Configuration og deretter Windows Configuration.
Utvid Sikkerhetsinnstillinger og lokale retningslinjer.
Velg mappen User Rights Assignment.
Retningslinjene vises i detaljpanelet.
I dette panelet dobbeltklikker du på alternativet Lås sider i minnet.
I dialogboksen Local Security Option - Memory Pages Lock velger du Legg til en bruker eller gruppe.
I dialogboksen Velg: Brukere, Tjenestekontoer eller Grupper legger du til kontoen du kjører MS SQL Server-tjenesten under.
For at endringene skal tre i kraft, start serveren på nytt eller logg på som brukeren du kjører MS SQL Server under.

Deaktiver DFSS for disker.

Dynamic Fair Share Scheduling-mekanismen er ansvarlig for å balansere og distribuere maskinvareressurser mellom brukere. Noen ganger kan driften påvirke ytelsen til 1C negativt. For å deaktivere den kun for disker, må du:

Finn HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TSFairShare\Disk-grenen i registeret
Sett EnableFairShare-parameterverdien til 0

Deaktiver datakomprimering for kataloger som inneholder databasefiler.

Når komprimering er aktivert, vil operativsystemet prøve å behandle filer i tillegg under endring, noe som vil redusere selve innspillingsprosessen, men vil spare plass.

For å deaktivere komprimering av filer i en katalog, må du:

Åpne katalogegenskaper
Klikk på Annet i kategorien Generelt
Fjern merket for "Komprimer" innholdsflagget for å spare diskplass.

Sett parameteren Max grad av parallellitet til 1.

Denne parameteren bestemmer hvor mange tråder en forespørsel kan kjøres i. Som standard er parameteren 0, noe som betyr at serveren selv velger antall tråder. For databaser med en typisk 1C-belastning anbefales det å sette denne parameteren til 1, fordi i de fleste tilfeller vil dette ha en positiv effekt på søkeytelsen.

For å konfigurere parameteren må du:

Åpne serveregenskaper og velg kategorien Avansert
Sett parameterverdien til én.

Begrens maksimal minnestørrelse for MS SQL Server.

Minne for MS SQL Server = Minne for alt – Minne for OS – Minne for 1C server

For eksempel har serveren 64 GB RAM installert, du må forstå hvor mye minne du skal tildele til DBMS-serveren slik at det er nok for 1C-serveren.

For normal drift av operativsystemet er i de fleste tilfeller 4 GB mer enn nok, vanligvis 2-3 GB.

For å finne ut hvor mye minne en 1C-server krever, må du se på hvor mye minne prosessene til en serverklynge opptar på høyden av arbeidsdagen. Disse prosessene er ragent, rmngr og rphost; disse prosessene er diskutert i detalj i delen dedikert til serverklyngen. Data bør tas nøyaktig i perioden med høy arbeidsaktivitet, når maksimalt antall brukere arbeider i databasen. Etter å ha mottatt disse dataene, må du legge til 1 GB til den - i tilfelle du starter "tunge" operasjoner i 1C.

For å angi maksimal mengde minne som brukes av MS SQL Server, må du:

Start Management Studio og koble til ønsket server
Åpne serveregenskaper og velg fanen Minne
Angi verdien for parameteren Maksimal serverminnestørrelse.

Aktiver Boost SQL Server-prioritetsflagget.

Dette flagget lar deg øke prioritet til MS SQL Server-prosessen fremfor andre prosesser.

Det er fornuftig å aktivere flagget bare hvis 1C-serveren ikke er installert på datamaskinen med DBMS-serveren.

For å sette flagget må du:

Start Management Studio og koble til ønsket server
Åpne serveregenskaper og velg fanen Prosessorer
Aktiver "Boost SQL Server priority"-flagget og klikk OK.

Angi størrelsen på automatisk voksende databasefiler.

Autogrow lar deg spesifisere hvor mye størrelsen på databasefilen skal økes med når den er full. Hvis du angir størrelsen for automatisk utvidelse for liten, vil filen utvides for ofte, noe som vil ta tid. Det anbefales å sette verdien fra 512 MB til 5 GB.

Start Management Studio og koble til ønsket server
Overfor hver fil i Auto-økning-kolonnen, legg inn den nødvendige verdien

Denne innstillingen vil kun gjelde for den valgte databasen. Hvis du vil at denne innstillingen skal gjelde for alle databaser, må du utføre de samme trinnene for modelltjenestedatabasen. Etter dette vil alle nyopprettede databaser ha samme innstillinger som modelldatabasen.

Skill mdf-datafiler og ldf-loggfiler på forskjellige fysiske disker.

I dette tilfellet kan arbeid med filer ikke fortsette sekvensielt, men nesten parallelt, noe som øker hastigheten på diskoperasjoner. SSD-stasjoner er best egnet for disse formålene.

For å overføre filer trenger du:

Start Management Studio og koble til ønsket server
Åpne egenskapene til ønsket database og velg Filer-fanen
Husk filnavn og plassering
Koble fra databasen ved å velge Oppgaver – Koble fra gjennom hurtigmenyen
Merk av for Slett tilkoblinger og klikk OK
Åpne Filutforsker og flytt datafilen og loggfilen til ønsket medium
I Management Studio åpner du serverkontekstmenyen og velger Legg ved database
Klikk på Legg til-knappen og spesifiser mdf-filen fra den nye disken
I det nedre databaseinformasjonsvinduet, på linjen med loggfilen, må du spesifisere den nye banen til transaksjonsloggfilen og klikke OK.

Mål: studere virkningen av SQL-parallellisme på arbeid med 1C-spørringer

Litteratur:

Test miljø:

Windows server 2008 R2 Enterprise

MS SQL server 2008 R2

· 1C Enterprise 8.2.19.90

Figur 1. SQL-egenskaper "Generelt"

Figur 2. SQL-egenskaper "Avansert"

Verktøy:

SQL server profiler

· 1C Query Console

Testforespørsel:

VELGE

AK.Name AS Navn

FRA

Informasjonsregister.Address Classifier AS AK

INDRE BLI MED Informasjonsregister.Address Classifier AS AK1

AV AK.Code = AK1.Code

Forberedelse:

Vi starter SQL Server Profiler, etablerer en tilkobling, merker hendelser og kolonner som vist i figur 3.

Figur 3. Sporegenskaper

Sette opp utvalg for vår database

Figur 4. Filtrer etter database

Forkortelser:

Maks grad av parallellitet – MDOP

Kostnadsterskel for parallellitet - kostnad

Testing av den sekvensielle spørringsplanen (MDOP = 1)

Figur 5. Spørrekonsoll – utførelsestid 20 sekunder.

SQL-serverparameteren "Maks grad av parallellitet" er satt til 1 (ingen parallellitet). Vi ser på resultatet i profileringsverktøyet (fig. 6)

Figur 6. Sekvensiell spørringsplan

SQL-serveren genererte en sekvensiell spørringsplan, med: total CPU-belastning = 6 750 (sek), og tid for å fullføre spørringen = 7 097 (sek)

Testing av parallell spørringsplan (MDOP = 0, kostnad =5)

Vi bytter SQL-server til parallellisme-modus (i SQL Query):

BRUK master ;

EXEC sp_configure "vis avansert alternativ" , 1;

REKONFIGURER MED OVERRID

BRUK master ;

exec sp_configure "maks grad av parallellitet" , 0;

REKONFIGURER MED OVERRID

Vi utfører den samme forespørselen (figur 7)

Figur 7. Spørrekonsoll – utførelsestid 16 sekunder.

Vi sjekker resultatet i profileringsverktøyet (Figur 8)

Figur 8. Parallell spørringsplan

Denne gangen genererte SQL-serveren en parallell spørringsplan, med total CPU-belastning = 7,905 sekunder og varighet for utføring av spørring = 3,458 sekunder

Testing av den sekvensielle spørringsplanen (MDOP = 0, kostnad = 150)

La oss prøve å bli kvitt den parallelle planen ved å bruke parameteren "Kostnadsterskel for parallellitet". Som standard er parameteren satt til 5. I vårt tilfelle klarte vi å kvitte oss med dannelsen av en parallell plan med en verdi på 150 (i SQL Query):

BRUK master ;

exec sp_configure "kostnadsterskel for parallellitet", 150 ;

Vi kontrollerer utførelsen av forespørselen under disse betingelsene (fig. 9)

Figur 9. Spørrekonsoll – utførelsestid 20 sekunder.

Vi sjekker resultatet i profileringsverktøyet (fig. 10)

Figur 10. Sekvensiell spørringsplan.

SQL-serveren genererte en sekvensiell spørringsplan. Total CPU-belastning = 7,171 sek, utføringstid for spørring = 7,864 sek.

Konklusjoner:

· Å utføre en testspørring i 1C Enterprise-miljøet ved å bruke en parallell spørringsplan for SQL-server gir en betydelig ytelsesøkning sammenlignet med den sekvensielle planen (16 sekunder versus 20 sekunder - gevinst på 4 sekunder)

· Å utføre en testspørring av SQL-serveren selv når du bruker en parallell spørringsplan er dobbelt så rask som når du bruker en sekvensiell spørringsplan (3,5 sekunder mot 7,1 sekunder)

· SQL-serverparallellisme kan justeres ikke bare ved å bruke MDOP-parameteren, men også parameteren "Kostnadsterskel for parallellitet"

I dette korte notatet vil jeg gjerne snakke litt om vanskelighetene med parallelle innstillinger i Microsoft SQL Server. Mange av dere har lenge vært klar over alternativet Max Degree od Parallelism, som har vært tilstede i SQL Server i svært lang tid. Som standard er den satt til 0, noe som betyr at SQL Server selv vil velge den optimale graden av parallellitet, det vil si antall prosessorer/tråder som brukes til å utføre én instruksjon. Nå vil jeg ikke stoppe og diskutere hvilken verdi det er bedre å angi dette alternativet - dette er et emne for et eget notat. Jeg skal bare se på hvordan verdien av dette alternativet påvirker utførelsen av spørringer. For eksempel, i figuren nedenfor, er dette alternativet satt til 1, noe som betyr at parallelle planer for alle spørringer er deaktivert som standard.

Dette alternativet er også tilgjengelig for visning ved hjelp av følgende T-SQL-kommando:

Faktisk vil enhver spørringsplan være sekvensiell som standard. For eksempel:

Utvikleren og enhver bruker har imidlertid fortsatt mulighet til å påvirke dette ved å bruke hint. For å gjøre dette trenger du bare å spesifisere ønsket grad av parallellitet, og den ønskede spørreplanen genereres, for eksempel:

Og hvis vi ser på denne spørringen gjennom sys.dm_exec_query_profiles-visningen, vil vi se at den faktisk utføres i 10 tråder.

Dermed gjenstår det et hemmelig hull i systemet som utviklere og brukere kan bruke for å "akselerere" (her setter jeg det i anførselstegn med vilje, fordi en høy grad av parallellitet ikke alltid fører til en reduksjon i utførelsestid for spørringer) deres spørringer ved å øke graden av parallellitet. Men på denne måten kan de ganske enkelt "drepe" serveren ved å kjøre mange ukontrollerte parallelle forespørsler samtidig. Hva kan vi gjøre med dette? Det er her Resource Governor kommer oss til unnsetning, et meget kraftig og fullstendig undervurdert system som lar deg fordele ressurser veldig fleksibelt mellom ulike brukergrupper. Igjen, jeg vil ikke dvele nå ved hvordan det fungerer og hvilke muligheter det har. Jeg skal bare gå i detalj om hvordan innstillingene for samtidighetsgrense påvirker den. La oss først ta en titt på standardinnstillingene:

Igjen ser vi at alternativet som standard er satt til 0 og beslutningen om å velge maksimal grad er overlatt til SQL Server. La oss nå se hva som skjer hvis jeg endrer denne verdien til 5. Vær oppmerksom, foreta ikke under noen omstendigheter slike innstillinger på et ekte system, fordi Jeg har ikke engang definert klassifiseringsfunksjonen for Resource Governor og endrer standardgruppen. Men for å teste og forstå hvordan alt fungerer spesifikt nå i mitt eksempel, er dette nok. Så jeg begrenser maksimal grad av parallellitet for alle til 5 tråder. La meg minne deg om at alternativet Maks grad av parallellisme, som vi så på tidligere er fortsatt satt til verdien 1. Hvis vi nå ser på utførelsesplanen for vår første spørring, vil den som standard være sekvensiell, og med maxdop 10-alternativet vil den være parallell. Men hvis vi kjører en parallell plan, vil vi se noe interessant.

Nå er vår forespørsel utført i bare 5 tråder, til tross for at alternativet maxdop den har en verdi på 10. Og hvis du spesifiserer maxdop 4-alternativet for forespørselen, vil det bli utført i 4 tråder (alternativet i Resource Governor er satt til 5). I dette tilfellet hintet maxdop mindre enn Ressursguvernør-innstillingen, så ingen ytterligere begrensning er pålagt. Jeg skal ikke lenger gi et eksempel på dette.

Dermed er Resource Governor et kraftigere verktøy som faktisk begrenser maksimal grad av parallellitet for spørringer, og denne graden kan settes forskjellig for ulike brukergrupper. I dette tilfellet, alternativet Maks grad av parallellisme fortsetter fortsatt å jobbe og gir sitt bidrag (eller forvirrer litt administratorer, utviklere og brukere når det fungerer sammen med Resource Governor). Videre er alternativene for å angi verdiene til disse 2 parameterne bare begrenset av fantasien din, men det er viktig å huske bare to ting: Maks grad av parallellisme og hint maxdop for en forespørsel påvirker det hvilken plan som vil bli generert, det maksimale antallet tråder som vil være mulig for denne forespørselen, og Ressursguvernøren begrenser forespørselen ovenfra under utførelse.

Opplæringen

Denne instruksjonen er ment for nybegynnere som leter etter en enkel guide på russisk for å installere den engelske versjonen av SQL Server 2012, som deretter vil bli brukt for SharePoint 2013.
Denne artikkelen er ikke for profesjonelle.

Alt arbeid er delt inn i 3 stadier:

Installere SQL Server 2012
Innstilling av serverkonfigurasjonsparameteren maksimal grad av parallellitet
Konfigurer rettighetene til kontoen som er ment å installere SharePoint 2013

Artikkelen beskriver også installasjonsprosessen av Microsoft .NET Framework 3.5 i MS Windows Server 2012 R2 Standard-miljøet.

OBS: det er mange bilder under snittet!

Installere SQL Server 2012

1. Før installasjon bør du sørge for at det er nok ledig plass på harddisken (i mitt tilfelle tok det 2,7 GB).
Etter å ha startet distribusjonen, velg " Installasjon" i menyen til venstre, klikk deretter " Ny SQL Server frittstående eller legg til funksjoner i en eksisterende installasjon":

2. Installasjonsveiviseren vil starte. Han vil sjekke. Du kan klikke på "Vis detaljer"-knappen og se en detaljert rapport:

3. Detaljert rapport. Klikk på "OK"-knappen:

4. Skriv inn produktnøkkelen og klikk på "Neste"-knappen:

5. Vi godtar vilkårene i lisensavtalen.
For å gjøre dette, merk av i boksen " Jeg godtar lisensvilkårene

6. I trinnet «Oppsett rolle» velger du det første elementet " Installasjon av SQL Server-funksjoner". Klikk på "Neste"-knappen:

7. Ved trinnet "Funksjonsvalg" merker du " Databasemotortjenester", "Administrasjonsverktøy – grunnleggende"Og" Administrasjonsverktøy – komplett". Klikk deretter på "Neste"-knappen:

8. Installasjonsprogrammet vil deretter utføre en ny sjekk. Du kan klikke på "Vis detaljer"-knappen og se en detaljert rapport:

9. Detaljert rapport. (På dette stadiet hadde jeg en feil i regelen "Microsoft .NET Framework 3.5 er installert...". Mer om det nedenfor). Klikk på "Neste"-knappen:

10. På trinnet "Forekomstkonfigurasjon" må du konfigurere SQL Server-tjenesteforekomsten.
Jeg gjentar at denne artikkelen er ment for nybegynnere. Derfor vil vi anta at SQL Server ikke har blitt installert på serveren din før, noe som betyr at vi vil forlate alle standardinnstillingene. Klikk på "Neste"-knappen:

11. På dette trinnet vil installasjonsveiviseren vise diskplasskravene. Klikk på "Neste"-knappen:

12. I trinnet "Server Configuration" må du spesifisere en domenekonto for tjenesten " SQL Server Database Engine". Etter å ha fylt ut "Kontonavn" og "Passord"-feltene, klikker du på "Neste"-knappen:

13. I trinnet "Database Engine Configuration" legger du bare til gjeldende bruker til SQL-serveradministratorene. For å gjøre dette, klikk på "Legg til nåværende bruker"-knappen, og klikk deretter på "Neste"-knappen:

14. I neste trinn klikker du på «Neste»-knappen:

15. Deretter vil installasjonsveiviseren utføre testen på nytt og vise resultatene. Klikk på "Neste"-knappen:

16. Ved trinnet "Klar til å installere" vil veiviseren vise sammendragsinformasjon. Her må du klikke på "Installer"-knappen:

17. Etter at installasjonen er fullført, vil informasjon om de utførte operasjonene vises:

18. Jeg anbefaler på det sterkeste å starte datamaskinen på nytt på dette stadiet. I noen tilfeller (for eksempel når du installerer Microsoft .NET Framework 3.5), vil selve installasjonsveiviseren vise et vindu som ber deg starte datamaskinen på nytt. Ikke nekt.

Innstilling av serverkonfigurasjonsparameteren maksimal grad av parallellitet

Standardverdien for parameteren Max Degree of Parallelism er 0.
SharePoint 2013 krever at denne innstillingen er 1.
Det er enkelt å fikse!

1. Lansering Microsoft SQL Server Management Studio(Start - Alle programmer - Microsoft SQL Server 2012 - SQL Server Management Studio).

2. Klikk på "Koble til"-knappen på servertilkoblingsskjermen.

3. Høyreklikk på serveren din i " Objektutforsker" og velg " Egenskaper":

4. I vinduet for serveregenskaper som åpnes, i venstremenyen, velg siden " Avansert" og bla gjennom listen over egenskaper helt til bunnen av skjermen. Still inn parameterverdien " Maks grad av parallellisme"V 1 og klikk OK:

5. Ikke lukk SQL Server Management Studio, vi trenger det senere.

Konfigurer rettighetene til kontoen som er ment å installere SharePoint 2013

Kontoen som SharePoint 2013 skal installeres under, må ha forhøyede rettigheter i SQL-serveren.
Det anbefales at denne kontoen får følgende roller:

dbcreator
sikkerhetsadmin
offentlig

1. I SQL Server Management Studio i " Objektutforsker"utvid element" Sikkerhet". Høyreklikk deretter på elementet " Pålogginger" og velg " Ny pålogging":

2. I feltet "Påloggingsnavn" skriver du inn domenenavnet til kontoen du planlegger å installere og konfigurere SharePoint 2013 under.

3. I menyen til venstre velger du siden " Serverroller" og sjekk rollene "dbcreator" og "securityadmin", og sørg også for at rollen "public" allerede er merket. Klikk deretter på "OK"-knappen:

Nå er SQL-serveren klar til å installere SharePoint 2013.

Installere Microsoft .NET Framework 3.5 i MS Windows Server 2012 R2 Standart

I trinn nummer 9 i punkt " Installere SQL Server 2012"Jeg fikk en feilmelding: .NET Framework 3.5 ble ikke installert.
For å løse dette problemet må du følge disse trinnene:

1. Du må åpne konsollen" Server Manager".

2. I menyen til venstre velger du elementet "Dashboard".

3. I midten av vinduet klikker du på "Legg til roller og funksjoner".

4. Hopp over trinnet "Før du begynner" i veiviseren som åpnes.

5. I trinnet "Installasjonstype", velg elementet " Rollebasert eller funksjonsbasert installasjon Klikk på "Neste"-knappen.

6. I neste trinn, la alt være standard og klikk på "Neste"-knappen.

7. Hopp over trinnet "Serverroller" ved å klikke på "Neste"-knappen.

8. Ved trinnet "Funksjoner", merk av for ".NET Framework 3.5-funksjoner". Klikk på "Neste"-knappen.

9. Når installasjonsprosessen er fullført, kan du lukke veiviseren for å legge til roller og funksjoner.

10. Ferdig!

Lykke til alle sammen og fredfull himmel over hodet!

P.S. Gratulerer med kommende kosmonautikkdag!

Maks grad av parallellisme (DOP) er et ekstra SQL Server-konfigurasjonsalternativ som har vært gjenstand for mange spørsmål og publikasjoner. I dette blogginnlegget håper forfatteren å gi litt klarhet i hva dette alternativet gjør og hvordan det bør brukes.
For det første ønsker forfatteren å fjerne enhver tvil om at alternativet som er oppført angir hvor mange prosessorer SQL Server kan bruke når de betjener flere tilkoblinger (eller brukere) - det gjør det ikke! Hvis SQL Server har tilgang til fire inaktive prosessorer, og den er konfigurert til å bruke alle fire prosessorene, vil den bruke alle fire prosessorene, uavhengig av maksimal grad av parallellitet.
Så hva gjør dette alternativet? Dette alternativet angir maksimalt antall prosessorer som SQL Server kan bruke for en enkelt spørring. Hvis en spørring til SQL Server må returnere en stor mengde data (mange poster), er det noen ganger fornuftig å parallellisere den ved å dele den opp i flere små spørringer, som hver vil returnere sitt eget undersett av rader. Dermed kan SQL Server bruke flere prosessorer, og derfor, på multiprosessorsystemer, kan et stort antall poster av en hel spørring potensielt returneres raskere enn på et enkeltprosessorsystem.
Det er mange kriterier som må vurderes før SQL Server påkaller "Intra Query Parallelism" (splitter en spørring i flere tråder), og det er ingen vits i å detaljere dem her. Du finner dem i BOL ved å søke på "Grad av parallellisme". Den sier at beslutningen om å parallellisere er basert på tilgjengeligheten av minne for prosessoren og spesielt på tilgjengeligheten til selve prosessorene.
Så hvorfor bør vi vurdere å bruke dette alternativet - fordi å la det stå på standardverdien (SQL Server tar sine egne parallelliseringsbeslutninger) kan noen ganger ha uønskede effekter. Disse effektene ser omtrent slik ut:

Parallelle spørringer går langsommere.

Utførelsestider for spørringer kan bli ikke-deterministiske, noe som kan irritere brukere. Utførelsestidene kan endres fordi:

Spørringen kan noen ganger parallellisere og noen ganger ikke.

En forespørsel kan blokkeres av en parallell forespørsel hvis prosessorene tidligere var overbelastet med arbeid.

Før vi fortsetter, vil forfatteren påpeke at det ikke er noe særlig behov for å dykke ned i den interne organiseringen av parallellisme. Hvis du er interessert i dette, kan du lese artikkelen «Parallell Query Processing» i Books on Line, som beskriver denne informasjonen mer detaljert. Forfatteren mener at det bare er to viktige ting å vite om den interne organiseringen av samtidighet:

Parallelle spørringer kan skape flere tråder enn det som er spesifisert i alternativet "Maks grad av parallellitet". DOP 4 kan skape mer enn tolv tråder, fire for spørring og tilleggstråder som brukes til sorteringer, strømmer, aggregater og sammenstillinger, etc.

Parallelle forespørsler kan føre til at forskjellige SPID-er venter med ventetypen CXPACKET eller 0X0200. Dette kan brukes til å finne de SPID-ene som er i ventetilstand under parallelle operasjoner og har en ventetype i sysprosesser: CXPACKET. For å gjøre denne oppgaven enklere, foreslår forfatteren å bruke den lagrede prosedyren som er tilgjengelig på bloggen hans: track_waitstats.

Og så "Spørringen kan være tregere når parallellisert" hvorfor?

Hvis systemet har svært lav gjennomstrømning av diskundersystemer, kan det ta lengre tid når du analyserer en forespørsel, enn uten parallellitet.

Det kan være dataskjevhet eller blokkering av dataområder for prosessoren forårsaket av en annen prosess brukt parallelt og lansert senere, etc.

Hvis det ikke er noen indeks på predikatet, noe som resulterer i en tabellskanning. Parallell operasjon i en spørring kan skjule det faktum at spørringen ville ha fullført mye raskere med en sekvensiell utførelsesplan og riktig indeks.

Fra alt dette følger det en anbefaling om å kontrollere utførelsen av forespørselen uten parallellitet (DOP=1), dette vil bidra til å identifisere mulige problemer.
Effektene av parallellisme nevnt ovenfor bør naturligvis få deg til å tro at den interne mekanikken til spørringsparallellisering ikke er egnet for bruk i OLTP-applikasjoner. Dette er applikasjoner der endring av utføringstider for spørringer kan være irriterende for brukere, og som det er usannsynlig at en server som betjener mange samtidige brukere vil velge en parallell utførelsesplan på grunn av den iboende prosessorens arbeidsbelastningsprofil for disse applikasjonene.
Derfor, hvis du skal bruke parallellisme, vil du mest sannsynlig trenge det for datainnhentingsoppgaver (datavarehus), beslutningsstøtte eller rapporteringssystemer, der det ikke er mange spørringer, men de er ganske tunge og utføres på en kraftig server med en stor mengde RAM-minne.
Hvis du bestemmer deg for å bruke parallellisme, hvilken verdi bør du sette for DOP? En god praksis for denne mekanismen er at hvis du har 8 prosessorer så sett DOP = 4 og dette vil mest sannsynlig være den optimale innstillingen. Det er imidlertid ingen garanti for at det vil fungere på denne måten. Den eneste måten å være sikker på er å teste forskjellige verdier for DOP. I tillegg til dette ønsket forfatteren å gi sitt empiriske råd om å aldri sette dette tallet til mer enn halvparten av antallet prosessorer som er tilgjengelig. Hvis forfatteren hadde færre enn seks prosessorer, ville han satt DOP til 1, som ganske enkelt deaktiverer parallellisering. Han kan gjøre et unntak hvis han hadde en database som bare støtter en enkelt brukerprosess (noen datainnhentingsteknologier eller rapporteringsoppgaver), i så fall, som et unntak, ville det være mulig å sette DOP til 0 (standardverdien), som lar SQL Server selv bestemme om en spørring skal parallelliseres.
Før han avsluttet artikkelen, ønsket forfatteren å advare deg om at parallell indeksoppretting avhenger av tallet du angir for DOP. Dette betyr at du kanskje vil endre det mens indekser blir opprettet eller gjenskapt for å forbedre ytelsen til denne operasjonen, og du kan selvfølgelig bruke MAXDOP-hintet i spørringen, som lar deg overstyre verdien satt i konfigurasjonen og kan brukes i rushtiden.
Til slutt kan søket ditt bli tregere når det parallelliseres på grunn av feil, så sørg for at serveren din har den nyeste oppdateringspakken installert.

CREATE proc track_waitstats (@num_samples int = 10 ,@delaynum int = 1 ,@delaytype nvarchar ( 10 )="minutter" ) AS -- T. Davidson -- Denne lagrede prosedyren leveres =SOM DEN ER= uten garantier,-- og gir ingen rettigheter. -- Bruk av inkluderte skripteksempler er underlagt vilkårene -- spesifisert på http://www.microsoft.com/info/cpyright.htm -- @num_samples er antall ganger for å fange opp ventestatistikker, -- standard er 10 ganger. standard forsinkelsesintervall er 1 minutt -- Delaynum er forsinkelsesintervallet. delaytype angir om -- forsinkelsesintervallet er minutter eller sekunder -- Lag ventestatstabell hvis den ikke eksisterer, ellers avkort sett nocount på hvis ikke eksisterer (velg 1 fra sysobjects der navn = "waitstats" ) lag tabell waitstats ( varchar ( 80 ), forespørsler numerisk ( 20 ,1 ), numerisk ( 20 ,1 ), numerisk ( 20 ,1 ), nå datetime default getdate ()) else trunkate table waitstats dbcc sqlperf (waitstats,clear) -- clear out waitstats declare @i int ,@delay varchar ( 8 ),@dt varchar ( 3 ),@nå datotid ,@totalwait numerisk ( 20 ,1 ) ,@sluttid dato klokkeslett ,@begynntid dato klokkeslett ,@hr int ,@min int ,@sek int velg @i = 1 velg @dt = små bokstaver (@delaytype) når "minutter" så "m" når "minutt" så "m" når "min" så "m" når "mm" så "m" når "mi" så "m" når "m" så "m" når "seconds" så "s" når "second" så "s" når "sec" så "s" når "ss" så "s" når "s" så "s" annet @ forsinkelsestype slutt hvis @dt ikke er i ("s" ,"m") begynner utskrift "Vennligst oppgi forsinkelsestype, f.eks. sekunder eller minutter" return end if @dt = "s" start velg @sec = @delaynum % 60 velg @min = cast ((@delaynum / 60 ) som int ) velg @hr = cast ((@min / 60 ) som int ) velg @min = @min % 60 end if @dt = "m" start velg @sec = 0 velg @min = @delaynum % 60 velg @hr = cast ((@delaynum / 60 ) som int ) end velg @forsinkelse = høyre ("0" + konverter (varchar ( 2 ),@hr), 2 2 ),@min), 2 ) + ":" + + høyre ("0" +konverter (varchar ( 2 ),@sek), 2 ) hvis @hr > 23 eller @min > 59 eller @sek > 59 begynne å velge "tt:mm:ss forsinkelsestid kan ikke > 23:59:59" velg "forsinkelsesintervall og skriv: " + konverter (varchar ( 10 ),@delaynum) + "," + @delaytype + " konverterer til " + @delay returslutt mens (@i<= @num_samples) begin insert into waitstats (, requests, ,) exec ("dbcc sqlperf(waitstats)" ) select @i = @i + 1 waitfor delay @delay End --- opprett ventestatsrapport utfør get_waitstats --//--//--//--//--//--//--//--//--//-//--//--//--//--//--//--//--//--/ LAG proc get_waitstats AS -- Denne lagrede prosedyren leveres =SOM DEN ER= uten garantier, og-- Gjelder ingen rettigheter. -- Bruk av inkluderte skripteksempler er underlagt vilkårene som er spesifisert -- på http://www.microsoft.com/info/cpyright.htm -- -- denne prosessen vil lage ventestatsrapport som viser ventetyper etter-- prosentandel -- kan kjøres når track_waitstats kjøres sett nocount på declare @now datetime ,@totalwait numeric ( 20 ,1 ) ,@sluttid datoklokkeslett ,@begintid datoklokkeslett ,@hr int ,@min int ,@sek int velg @now=maks (nå),@begintime=min (nå),@sluttid=maks (nå) fra ventestatistikk hvor = " Total" --- trekk fra waitfor, sleep og resource_queue fra Total velg @totalwait = sum() + 1 fra ventestatistikk der ikke i ("WAITFOR", "SLEEP", "RESOURCE_QUEUE", "Total", "***total***") og nå = @nå - sett inn justerte totaler, ranger etter prosentvis synkende slett waitstats hvor = "***total***" og nå = @now sett inn i waitstats velg "***total***" , 0 ,@totalwait ,@totalwait ,@velg nå , ,prosent = cast ( 100 */@totalwait som numerisk ( 20 ,1 )) fra waitstats der ikke i ("WAITFOR", "SLEEP", "RESOURCE_QUEUE", "Total") og nå = @nå bestill etter prosentvis desc