Database Autoshrink

Class Exchange packets, or CX packets, are a wait type that occurs when you try to synchronize the query processor exchange iterator. CX packets are only generated when you make parallel queries. When you start get large CX packet waits, it means that one thread of the query is waiting for a message packet from another, and the one it is waiting on is either blocked by a database/network issue or is being stopped by some type of parallelism issue. If the wait type becomes a problem, lower the degree of parallelism.

Breaking down the term, packet means the system is waiting on a data packet; that is, waiting on the results of an internal query to be received. Exchange means the system is waiting on a control packet; that is, waiting for a child/sibling process to inform you it has completed.

According to an Idera blog on SQL Server wait stats, CX packet waits occur when a parallel query is executed and one or more threads must wait on another threads to finish. A CX packet measures the time spent in the waiting threads of a parallel query.

As the blog explains, some CX packet waits are inevitable with multi-thread parallel queries, but a significant backlog of CX packet waits means you have network problems or parallelism issues that need addressing: “SQL Server will parallelize a query by dividing each operation into equal sized sets for processing.  These sets are then split up into multiple threads targeting specific processors.  This allows each thread to be executed in parallel by each of the processors.  Even with SQL Server splitting up the work into equal-sized pieces, it is still impossible for all of the threads to complete at exactly the same time to prevent one or more of the threads from experiencing CXPACKET waits.  In short, if you have parallel query execution you will have CXPACKET waits.”