CXPACKET, while not necessarily an issue on its own, is something that cannot be ignored, as it can indicate a problem someplace else that can be improved - if threads are waiting on each other (which is what CXPACKET mean), that means that there is a thread that waits longer than others for something else, if that wait can be eliminated or reduced, the entire workload will be improved.
We cannot set the performance health to ignore all waits that cause the score to degrade as this will contradict the meaning of the score. Note that the score only indicates that the instance is not performing as efficiently as possible which is correct in this case where there is a lot of CXPACKET waiting.
The threshold of the health score alarm can be reduced. You can use the wait event dashboard to check what statement/database/program etc waited on CXPACKET.
Also in SQL Server 2016 SP2 and later or SQL Server 2017 CU3 and later CXPACKET is definitely a bad wait. Previously CXPACKET waits were used in two scenarios, one good and one bad, but these updates added the CXCONSUMER wait which replaces the formerly good CXPACKET wait. See https://blogs.msdn.microsoft.com/sql_server_team/making-parallelism-waits-actionable/
© 2025 Quest Software Inc. ALL RIGHTS RESERVED. Terms of Use Privacy Cookie Preference Center