可以設置 max dop = number of cpu 的原因導致單個查詢阻塞其他查詢的情況嗎?
我有 8 個 CPU 的 sql 伺服器。最大工作執行緒設置為 850。最大 dop 為 8。並行度的成本執行緒保持為 50。
這意味著 sql server 會將超過成本門檻值的查詢分解為 8 個執行緒。由於每個執行緒都在一個 cpu 上執行,那麼這是否意味著在目前執行的 8 個執行緒中的至少一個被釋放之前,不允許其他使用者執行查詢?
那麼設置 max dop = number of cpu’s cause case 單個查詢會阻塞其他查詢嗎?
除了其他文章:
一旦一個任務被授予訪問核心的權限,它大約有 4 毫秒的時間來做它想做的事情。大約 4 毫秒後,它會產生,因此下一個隊列將被授予訪問核心的權限(協作多任務處理)。
在任務被授予對核心的訪問權限後,您可以有 3 種不同的結果:
- 它在約 4 毫秒之前完成,會話回到睡眠狀態。接下來是核心。
- 它還沒有完成——它需要更多的 CPU 並被放在隊列的最後(信號等待)。接下來是核心。
- 它在 ~4ms 之前遇到等待(例如鎖定)並被放入等待列表(資源等待)。接下來是核心。
以上均未導致阻塞。
當然,執行緒不會自行放棄核心(不屈服)可能會出現問題,但這不正常,應該在這種情況下進行故障排除。
MAXDOP
是用於處理特定執行查詢的查詢計劃的並行化分支的額外工作執行緒的****最大並行度(或對於所有查詢,在伺服器級別,如果以這種方式提供)。這意味著它是一個上限門檻值,以確保查詢的運算符分支在執行時不能同時超過****該執行緒數。伺服器上的預設設置是 0,這意味著查詢計劃的操作分支可以進行多少並行度沒有限制。因此,通過設置
MAXDOP
,您不會比現有的預設設置更差。實際上,在具有 8 個 CPU 的範例伺服器中,設置MAXDOP
為 8 與預設值 0 即無門檻值相同。有關適當配置的更多資訊,請參閱 Brent Ozar 的配置並行混淆。要記住的另一件有趣的事情
MAXDOP
是,並行化計劃的整個查詢計劃的最大並發執行執行緒數可以達到設置為加 1 的任何值。這是因為仍然有原始執行緒充當父任務為計劃的並行分支中的不同操作員觸發和協調其他並行執行緒。