CXSYNC_CONSUMER is one of the newer parallelism waits, recorded when consumer threads in a parallel plan wait to reach an exchange iterator synchronisation point. It first appeared in Azure SQL Database and Managed Instance and arrived on-premises with SQL Server 2022, where it was split out of CXPACKET (together with CXSYNC_PORT) to make parallel plan investigation more precise.
If you upgraded to 2022 and “new” CX waits appeared, nothing changed in your workload; the accounting just got finer-grained.
Is It a Problem?
Read it the way you read CXPACKET: it proves parallel plans are running, which is often exactly what you want. Do not reflexively cut MAXDOP to make it go away. It earns investigation when it dominates on a workload that should not be running heavy parallel queries, or when it grows alongside user complaints about specific queries.
The consumer-side split helps: high CXSYNC_CONSUMER with modest CXPACKET leans toward consumers waiting on slow producers, the classic skew signature.
Common Causes
- Legitimate parallel query work on reporting and batch workloads.
cost threshold for parallelismleft at the default 5, parallelising trivial queries.- Skewed work distribution between parallel threads (stale statistics, uneven data).
- Missing indexes forcing large parallel scans.
What To Do
- Identify the parallel queries involved (
sys.dm_exec_query_statsfiltered to parallel plans, ordered by elapsed time). - Raise
cost threshold for parallelismto 25-50 so only genuinely expensive queries go parallel. - Fix skew at the source: update statistics, index the scan-driving predicates.
- Tune MAXDOP per workload if needed, but as a considered setting, not a reaction to this wait existing.
How To See It
Rank it against everything else with Get-WaitStatistics. Read it together with CXPACKET, CXCONSUMER, and CXSYNC_PORT as one parallelism picture.
Part of the SQL Server Wait Types Library.
Related deep dive: CXPACKET and CXCONSUMER Wait Types.
Leave a Reply