(Republisering, Eller Bruk av denne informasjonen i et kommersielt produkt/nettsted, er forbudt uten tillatelse. All annen bruk er tillatt. Hvis du er i tvil, spør.)
(Tilbake til hovedsiden…)
Beskrivelse:
den enkleste forklaringen på denne ventetypen er at det er parallelle planer som kjører. Mye har blitt skrevet om denne ventetypen og hva du skal gjøre med det, og dessverre er det mange dårlige råd der ute. Når en utveksling iterator (f. eks. Kjøre, vil det være minst EN cxpacket vente (for kontroll tråden), og muligens andre hvis det er en skjev fordeling av arbeidet.
ikke bare reduser serveren MAXDOP for å prøve å redusere eller fjerne disse! Vennligst les detaljerte forklaringer og råd i linkene nedenfor.
(Books online description: «Oppstår med parallelle spørringsplaner når du prøver å synkronisere query processor exchange-iteratoren. Hvis ventingen er overdreven og ikke kan reduseres ved å justere spørringen (for eksempel legge til indekser), bør du vurdere å justere kostnadsterskelen for parallellisme eller redusere graden av parallellisme.»)
Spørsmål / kommentarer på denne ventetypen? Klikk her for å sende Paul en e-post, spesielt hvis Du har noen informasjon å legge til dette emnet.
Lagt TIL I SQL Server-versjon:
Pre-2005/2005
Fjernet I SQL Server-versjon:
I / T
Utvidede Hendelser wait_type-verdi:
map_key-verdien i sys.dm_xe_map_values er 187 I 2008 Og 2008 R2, og 191 I 2012 OG 2014 RTM. ETTER 2014 RTM, må DU sjekke DMV å få den siste verdien som noen map_key verdier har endret seg i senere bygger.
Annen informasjon:
knee-jerk-reaksjonen PÅ CXPACKET waits er å prøve å fjerne eller redusere dem. Dette er feil da de kan være en helt normal del av arbeidsbelastningen din. Du må undersøke hvor de forekommer og avgjøre om parallelliteten er gyldig eller ikke, og hvis gyldig, fungerer normalt eller om det skjer skjev parallellisme.
jeg skrev to detaljerte artikler om forståelse OG feilsøking CXPACKET venter på sqlperformance.com:
- Knee-Jerk Ventestatistikk: CXPACKET
- Mer OM CXPACKET Waits: Skjev Parallellitet
Merk at I 2016 SP2, 2017 RTM CU3 OG Azure SQL Database er CXPACKET vent delt slik at godartet, ikke-handlingsbar parallellitet venter nå vises SOM CXCONSUMER venter. Dette betyr at DET bør være færre CXPACKET venter, og de som forblir, er mer sannsynlig å være indikative for et ytelsesproblem.
Kjente forekomster I SQL Server (listenummer samsvarer med anropsstakkliste):
stablene nedenfor er alle eksempler på parallelle tråder fra ulike spørringsplanoperatorer. Det er mange, mange flere forekomster med lignende stabler.
Forkortede anropsstabler (listenummer samsvarer med kjente forekomster liste):
- SOS_Task::PostWait+90
EventInternal::Wait+2c6
EventInternal::WaitAllowPrematureWakeup+c7
CXPipe::Pull+156
CXTransLocal::AllocateBuffers+64
CQScanXProducerNew::AllocateBuffers+31
CQScanXProducerNew::GetRowHelper+293
CQScanXProducerNew::GetRow+15
FnProducerOpen+57
FnProducerThread+851
SubprocEntrypoint+a59
SOS_Task::Param::Execute+21e
SOS_Scheduler::RunTask+a8 - SOS_Task::PostWait+90
EventInternal::Wait+2c6
EventInternal::WaitAllowPrematureWakeup+c7
XchngWait+b5
CXPort::Open+147
CQScanXProducerNew::Open+da
FnProducerOpen+44
FnProducerThread+851
SubprocEntrypoint+a59
SOS_Task::Param::Execute+21e
SOS_Scheduler::RunTask+a8 - SOS_Task::PostWait+90
EventInternal::Wait+2c6
EventInternal::WaitAllowPrematureWakeup+c7
CXPacketList::RemoveHead+e9
CXPipe::ReceivePacket+7a
CXTransLocal::ReceiveBuffers+2d
CQScanExchangeNew::GetRowFromProducer+5f
CQScanExchangeNew::GetRowHelper+66
CQScanSortNew::BuildSortTable+2a6
CQScanSortNew::OpenHelper+c0
CQScanNew::OpenHelper+41
CQScanStreamAggregateNew::Open+30
CQScanNLJoinNew::Open+24
CQScanSortNew::BuildSortTable+3a
CQScanSortNew::OpenHelper+c0
CQScanNew::OpenHelper+41
CQScanXProducerNew::Open+c8
FnProducerOpen+44
FnProducerThread+851
SubprocEntrypoint+a59
SOS_Task::Param::Execute+21e
SOS_Scheduler::RunTask+a8 - SOS_Task::PostWait+90
EventInternal::Wait+2c6
EventInternal::WaitAllowPrematureWakeup+c7
XchngWait+b5
CXPort::Open+147
CQScanExchangeNew::Open+104
CQScanHash::ConsumeBuild+fd
CQScanHash::Open+8e
CQScanSortNew::BuildSortTable+3a
CQScanSortNew::OpenHelper+c0
CQScanNew::OpenHelper+41
CQScanXProducerNew::Open+c8
FnProducerOpen+44
FnProducerThread+851
SubprocEntrypoint+a59
SOS_Task::Param::Execute+21e
SOS_Scheduler::RunTask+a8