CXSYNC_PORT is the second of the parallelism waits split out of CXPACKET for Azure SQL Database and SQL Server 2022. It is recorded when parallel plan threads wait to open, close, and synchronise exchange iterator ports, the connection points through which producer threads hand rows to consumer threads. A long-running blocking operator, a big sort feeding an exchange for example, can hold a port and put upstream threads into this wait.
Like its sibling CXSYNC_CONSUMER, seeing it after an upgrade means finer accounting, not new problems.
Is It a Problem?
Treat it as part of the CX family: evidence of parallelism, not proof of trouble, and not a reason to slash MAXDOP. Where it adds diagnostic value is pointing at plan shape: sustained port waits often accompany plans where a blocking operator (sort, hash build, spool) sits between producers and consumers, so one stage of the plan gates the rest.
If it climbs while specific queries regress, look at those plans rather than at server settings first.
Common Causes
- Parallel plans with blocking operators holding exchange ports while they complete.
- Big sorts and hash builds fed by parallel scans.
- Skewed or misestimated inputs stretching the gating operator’s runtime.
- Trivial queries going parallel due to a low cost threshold.
What To Do
- Capture the plans behind the wait and look for the blocking operator feeding an exchange; that operator’s input is the real tuning target.
- Reduce the sorted or hashed volume: indexes that provide order, tighter predicates, fresh statistics for accurate memory grants.
- Keep parallelism settings sensible (
cost threshold for parallelism25-50, deliberate MAXDOP), as with the whole CX family.
How To See It
Rank it against everything else with Get-WaitStatistics, alongside CXPACKET, CXCONSUMER, and CXSYNC_CONSUMER.
Part of the SQL Server Wait Types Library.
Related deep dive: CXPACKET and CXCONSUMER Wait Types.
Leave a Reply