SQL Server 似乎因 Hyperthreading 誤判

先前碰過兩個朋友在 Threading 上的問題，都是效能差。其解法一是將 SQL Server 執行個體的 max degree of parallelism 設為 1，另一是減半。也就是不要平行執行計畫或是不要 Hyperthreading。其效能都變好了。

今天看到 MVP 的 mailing list 中討論，就微軟的回答，似乎 Hyperthreading 只適用於 OLTP 大量使用者存取，但其語法都很簡單的情況。

若 OLTP 單一 batch 很複雜，或是 DW/DSS/OLAP 以分析為主，需要大量平行運算的的工作，最好都使用實體的 CPU 數(不是主機板上的 socket 數)，其理由為：SQL Server 以所有的 CPU 運算力都相同為前提，設計平行計畫。但 Hyperthreading 的 CPU 並非如此。其建議是：

• 在語法上採用 MAXDOP <實體 CPU 數>。Ex: SELECT … FROM … OPTION(MAXDOP 1)
• 可以針對連接透過 Resource Governer 設定 CPU 數，但非所有版本的 SQL Server 都能使用這項功能。

當然，也可以透過執行個體的 max degree of parallelism 設定

而該問題的癥兆之一是 Wait type 中，CXPACKET 類型的 Wait 量很大。

另外，有一篇 Blog 針對 CXPACKET Demo： A closer look at CXPACKET wait type in SQL Server，其內沒有比較 Hyperthreading 讓效率不佳的原因(就我依他的範例語法修改 MAXDOP 其執行所耗時間沒太大差異)，但可以讓人較了解平行運算

數日後，朋友告知因為她們是 8 核實體 CPU 加上 Hyperthreading，最後是以 affinity 限制可用的 CPU

sp_configure ‘affinity I/O mask’, 255;
GO
RECONFIGURE WITH OVERRIDE;
GO

sp_configure ‘affinity mask’, 255;
GO
RECONFIGURE WITH OVERRIDE;
GO

個人感覺，因為只有 SQL Server，或許可以直接在 BIOS 關掉 Hyperthreading。但她們不想再試了…