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。但她們不想再試了…

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 變更 )

Twitter picture

You are commenting using your Twitter account. Log Out / 變更 )

Facebook照片

You are commenting using your Facebook account. Log Out / 變更 )

Google+ photo

You are commenting using your Google+ account. Log Out / 變更 )

連結到 %s

%d 位部落客按了讚: