Sql-Server

NUMA 節點 - MAXDOP - PLE

  • August 20, 2015

我們有一個伺服器,在 2 個 NUMA 上具有 8 個 CPU,並啟用了超執行緒。目前 Maxdop 設置為 8,但實際上應該根據本文的 Maxdop 部分設置為 4:

https://support.microsoft.com/en-us/kb/322385

所以我們需要把它改成4。

但是我的問題是將 maxdop 設置為 8 有什麼影響?那麼跨兩個 NUMAS 並行?我問的原因是我們剛剛遇到了一個奇怪的問題,即查詢返回非常緩慢,而 PLE 迅速下降。

即使沒有針對 SQL PLE 執行,也沒有改善。CXPACKET 等待類型增加。然後突然 CXPACKET 等待類型完全下降,PLE 開始上升,現在已經恢復正常。

在這段時間裡,對數據庫執行了小查詢,但是並不是一個查詢完成導致 CXPACKET 等待類型下降而 PLE 再次上升——我們不知道是什麼原因造成的。

一個可能的解釋是不正確的 MAXDOP 設置。

誰能向我解釋跨 NUMA 節點並行執行的影響,它是否與使用外部記憶體時耗盡工作執行緒和更慢的訪問時間一樣?

謝謝

SQL 伺服器 2005 SP3

首先最好的選擇是將其升級到受支持的 SP -首先下載 SP4,然後下載 CU3 –> Build NO: 9.00.5266。對 SQL Server 2005 的支持將於明年 (2016/04/12) 結束,即使是對最新的 SP 和 CU 也是如此——因此更好地升級到 2012/2014。

您可以使用我的腳本來幫助您建議一個好的 MAXDOP 值

誰能向我解釋跨 NUMA 節點並行執行的影響,它是否與使用外部記憶體時耗盡工作執行緒和更慢的訪問時間一樣?

SQL 伺服器支持 NUMA。這意味著 SQL Server 知道處理器在哪個 NUMA 節點以及記憶體在哪個 NUMA 節點。因此,SQL Server 將在正確的 NUMA 節點上為您要訪問的數據分配工作執行緒。

參考:

以下是一些查詢,可幫助您了解 NUMA 節點之間的調度程序是否不平衡- 這可能會導致負載下出現嚴重的性能問題:

SELECT 
 parent_node_id,
 scheduler_id, 
 [cpu_id], 
 is_idle, 
 current_tasks_count, 
 runnable_tasks_count, 
 active_workers_count, 
 load_factor
FROM sys.dm_os_schedulers
WHERE [status] = N'VISIBLE ONLINE';

--- check the current tasks, runnable tasks, active workers and avg load factor COUNT ...
SELECT 
 parent_node_id, 
 SUM(current_tasks_count) AS current_tasks_count, 
 SUM(runnable_tasks_count) AS runnable_tasks_count, 
 SUM(active_workers_count) AS active_workers_count, 
 AVG(load_factor) AS avg_load_factor
FROM sys.dm_os_schedulers
WHERE [status] = N'VISIBLE ONLINE'
GROUP BY parent_node_id;

您應該監控SQL Server:Buffer NodeSQL Server, Memory Node不是僅僅監控 PLE - 監控各個Buffer Node:Page life expectancy計數器(每個 NUMA 節點將有一個緩衝區節點性能對象)。

耗盡工作執行緒

如果您將 MAXDOP 設置設置為預設值(即 0),那麼它可能會導致工作執行緒飢餓。

引用自:https://dba.stackexchange.com/questions/103162