高 CXPACKET 和 LATCH_EX 等待
我正在使用的數據處理系統存在一些性能問題。我從一小時周期中收集了等待統計資訊，這些統計資訊顯示了大量的 CXPACKET 和 LATCH_EX 等待事件。
該系統由 3 個處理 SQL Server 組成，它們進行大量的數字運算和計算，然後將數據輸入中央集群伺服器。處理伺服器在任何時候最多可以執行 6 個作業。這些等待統計資訊適用於我認為導致瓶頸的中央集群。中央集群伺服器有 16 個核心和 64GB RAM。MAXDOP 設置為 0。
我猜 CXPACKET 來自執行的多個並行查詢，但是我不確定 LATCH_EX 等待事件表示什麼。根據我的閱讀，這可能是非緩衝等待？
誰能建議這些等待統計數據的原因是什麼，以及我應該採取什麼行動來調查這個性能問題的根本原因？
頂部查詢結果是總等待統計資訊，底部查詢結果是 1 小時內的統計資訊
CXPACKET 可以與 LATCH_XX 一起使用（也可能與 PAGEIOLATCH_XX 或 SOS_SCHEDULER_YIELD 一起使用）。如果是這種情況（根據問題，我相信是這樣），那麼應該降低 MAXDOP 值以適合您的硬體。
除此之外，這裡有一些更推薦的步驟來診斷高 CXPACKET 等待統計值的原因（在 SQL Server 上更改某些內容之前）：
- 不要將 MAXDOP 設置為 1，因為這永遠不是解決方案
- 調查查詢和 CXPACKET 歷史以了解並確定它是否只發生了一次或兩次，因為它可能只是系統中正常工作的異常
- 檢查查詢使用的表的索引和統計資訊，並確保它們是最新的
- 檢查並行成本門檻值 (CTFP) 並確保使用的值適合您的系統
- 檢查 CXPACKET 是否帶有 LCK_M_XX（通常帶有 IO_COMPLETION 和 ASYNC_IO_COMPLETION）。如果是這種情況，那麼並行性就不是瓶頸。對這些等待統計資訊進行故障排除，以找到問題的根本原因和解決方案
如果您確實需要深入了解 CXPACKET 等待類型，我建議您閱讀SQL Server 中的 CXPACKET 等待類型疑難解答一文
閱讀Diagnosing and Resolving Latch Contention on SQL Server，是關於該主題的最全面的論文。您必須深入研究
sys.dm_os_latch_stats並查看爭用的閂鎖類型。看看閱讀如何分析 SQL Server 性能是否對您有任何幫助。