(publicera eller använda denna information i en kommersiell produkt/webbplats, är förbjudet utan tillstånd. All annan användning är tillåten. Om du är osäker, fråga.)
(tillbaka till huvudsidan…)
beskrivning:
den enklaste förklaringen av denna väntetyp är att det finns parallella planer som körs. Mycket har skrivits om denna väntetyp och vad man ska göra åt det, och tyvärr finns det många dåliga råd där ute. När en exchange iterator (t. ex. Det kommer att finnas minst en cxpacket vänta (för kontrollgängan), och eventuellt andra om det finns en skev arbetsfördelning.
minska inte bara servern MAXDOP för att försöka minska eller ta bort dessa! Läs detaljerade förklaringar och råd i länkarna nedan.
(Books Online description: ”förekommer med parallella frågeplaner när du försöker synkronisera frågeprocessorns utbyte iterator. Om väntetiden är överdriven och inte kan minskas genom att ställa in frågan (som att lägga till index), överväg att justera kostnadsgränsen för parallellism eller sänka graden av parallellism.”)
frågor / kommentarer på denna vänta typ? Klicka här för att skicka Paul ett mail, särskilt om du har någon information att lägga till detta ämne.
Tillagd i SQL Server-version:
Pre-2005/2005
borttagen i SQL Server-version:
N/A
utökade händelser wait_type-värde:
map_key-värdet i sys.dm_xe_map_values är 187 i 2008 och 2008 R2 och 191 i 2012 och 2014 RTM. Efter 2014 RTM måste du kontrollera DMV för att få det senaste värdet eftersom vissa map_key-värden har ändrats i senare byggnader.
Övrig information:
knee-jerk-reaktionen på CXPACKET waits är att försöka ta bort eller minska dem. Detta är felaktigt eftersom de kan vara en helt normal del av din arbetsbelastning. Du måste undersöka var de förekommer och avgöra om parallellen är giltig eller inte, och om den är giltig, fungerar normalt eller om det sker skev parallellism.
jag skrev två detaljerade artiklar om förståelse och felsökning CXPACKET väntar på sqlperformance.com:
- knä-Jerk vänta statistik: CXPACKET
- mer om Cxpacket väntar: skev parallellitet
Observera att i 2016 SP2, 2017 RTM CU3, och Azure SQL Database, cxpacket vänta har delats så att godartade, icke-angripbara parallellitet väntar nu dyker upp som CXCONSUMER väntar. Detta innebär att det bör finnas färre CXPACKET väntar, och de som finns kvar är mer benägna att vara ett tecken på ett prestandaproblem.
kända händelser i SQL Server (listnummer matchar call stack list):
staplarna nedan är alla exempel på parallella trådar från olika frågeplanoperatörer. Det finns många, många fler händelser med liknande staplar.
förkortade samtalsstackar (listnummer matchar listan över kända händelser):
- 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