ハイパースレッディングを無効にすると、SQL Serverインストールのパフォーマンスが向上します
関連： SQL Serverとハイパースレッディングの現在の知識
最近、Windows 2008 R2データベースサーバーを X547 から X556 にアップグレードしました。理論的には、どちらのCPUも非常に似たパフォーマンスを発揮しますが、X5560の方が少し高速です。
ただし、SQL Server 2008 R2のパフォーマンスは過去1日ほどの間かなり悪く、CPU使用率はかなり高くなっています。
ページの平均寿命は非常に長く、ページのキャッシュヒットはほぼ100％なので、メモリは問題ではありません。
私が走ったとき：
SELECT * FROM sys.dm_os_wait_stats
order by signal_wait_time_ms desc
私が得た：
wait_type waiting_tasks_count wait_time_ms max_wait_time_ms signal_wait_time_ms ----------------------------------- ------------------------- -------------------- ----- --------------- -------------------- --------------- ----- [.____。 SLEEP_TASK 170743505 1525669557 1406 76485386 [.____。 1475699 （10行が影響を受けました）
私も走った
-- Isolate top waits for server instance since last restart or statistics clear
WITH Waits AS (
SELECT
wait_type,
wait_time_ms / 1000. AS [wait_time_s],
100. * wait_time_ms / SUM(wait_time_ms) OVER() AS [pct],
ROW_NUMBER() OVER(ORDER BY wait_time_ms DESC) AS [rn]
FROM sys.dm_os_wait_stats
WHERE wait_type NOT IN ('CLR_SEMAPHORE','LAZYWRITER_SLEEP','RESOURCE_QUEUE',
'SLEEP_TASK','SLEEP_SYSTEMTASK','SQLTRACE_BUFFER_FLUSH','WAITFOR','LOGMGR_QUEUE',
'CHECKPOINT_QUEUE','REQUEST_FOR_DEADLOCK_SEARCH','XE_TIMER_EVENT','BROKER_TO_FLUSH',
'BROKER_TASK_STOP','CLR_MANUAL_EVENT','CLR_AUTO_EVENT','DISPATCHER_QUEUE_SEMAPHORE',
'FT_IFTS_SCHEDULER_IDLE_WAIT','XE_DISPATCHER_WAIT', 'XE_DISPATCHER_JOIN'))
SELECT W1.wait_type,
CAST(W1.wait_time_s AS DECIMAL(12, 2)) AS wait_time_s,
CAST(W1.pct AS DECIMAL(12, 2)) AS pct,
CAST(SUM(W2.pct) AS DECIMAL(12, 2)) AS running_pct
FROM Waits AS W1
INNER JOIN Waits AS W2 ON W2.rn <= W1.rn
GROUP BY W1.rn, W1.wait_type, W1.wait_time_s, W1.pct
HAVING SUM(W2.pct) - W1.pct < 95; -- percentage threshold
そして得た
wait_type wait_time_s pct running_pct CXPACKET 554821.66 65.82 65.82 LATCH_EX 184123.16 21.84 87.66 SOS_SCHEDULER_YIELD 37541.17 4.45 92.11 [.____._ 53._53._AT._53 .____._ 53 .____.____.____.____.________________ 26.SH.26 FT_IFTSHC_MUTEX 14306.05 1.70 96.07
これは、並列処理を伴うクエリの同期に膨大な時間がかかることを示しています（高いCXPACKET）。さらに、これらの問題のあるクエリの多くは、複数のコアで実行されています（コードのどこにもMAXDOPヒントはありません）。
サーバーに1日以上負荷がかかっていない。クエリの実行には大きなばらつきがあり、通常、多くのクエリは以前のDBサーバーよりも遅く、CPUが非常に高いようです。
ハイパースレッディングを無効にすると、CPU使用率が低下し、スループットが向上しますか？
特定のワークロードをテストするは、元の回答のとおり、確認する唯一の方法であるとまだ感じています。本番システムをチューニングしようとするときは理想的な答えではありませんが（パフォーマンスと可用性の両方が本当に重要なシステムで同じテストベッドを取得できるかどうかを尋ねます）、それが私が本当に快適な唯一のものですと。
ハイパースレッディングが一般的に物事を傷つけたり改善したりするべきかどうかの理論について話すことができます（サーバーでのヘルプよりも傷つく可能性が高いので、「一般的な」展開ではおそらく無効にします）。特定のケースで違いが出るかどうかを確認する唯一の方法は、それを試してみることです。
私はそれに賛成だ
- bestでの推奨は、「ワークロードでハイパースレッディングを試し、何が起こるかを確認する」ことです。私がタイプしている間、私たちは今これを行っています、そしてそれは..それは良くありません！
- 最も安全なので、常にハイパースレッディングを無効にして開始する必要があります
2つの調整が必要なようです。
MAXDOP（最大並列度）。私が読んだすべては、これを無制限にすることはおそらく悪い考えであることを示しています Microsoftのドキュメント はこう言っています：
このオプション[MAXDOP]を[8より大きい]大きな値に設定すると、多くの場合、不要なリソースの消費とパフォーマンスの低下を引き起こします。
8以上の値は一般的には推奨されません..とりあえず4に設定します。最初はゼロ（無制限）でした。並列処理のコストしきい値。どうやら、ここでの
5のデフォルトは、私が見つけたいくつかのSQL MVPの投稿によると、かなり低いデフォルトと見なされています （それを調整 して、並列処理の試行回数を減らすことができますスケジューラ。
しかし正直なところ、これらは回避策のように感じます。私たちのワークロード（フルテキストインデックスが重い）の真の解決策は、HTを無効にすることだと思います。
Anandtechは、純粋な読み取り負荷では少し傷つき、書き込み負荷が高いと少し勝つことを発見しました。 -5％よりもはるかに悪いヒット、または15％よりもはるかに良い勝利をもたらすと私に思わせるようなものは何も見ていません。 Atomの場合、これは大きな勝利ですが、それは非常に奇妙なCPUです。
変更したのはCPUだけですか？ 12MBのキャッシュと4つのスレッド、つまりスレッドごとに3MBのキャッシュから、8MBのキャッシュと8つのスレッド、つまりスレッドごとに1MBになりました。さて、それは単純化しすぎですが、私はそれがあなたを殺しているものだと思います、あなたはキャッシュでクエリを実行し、今ではRAMから実行する必要があります。 HTをオフにするとおそらく役立つでしょうが、私は古いCPUに戻ります。HTをオフにすると、スレッドごとに2MBが得られますが、ワークロードがそれだけスラッシュする場合、それは役に立たないでしょう。 12MBのキャッシュCPUは、ワークロードに対して非常に高速です。
私はHTをオフにしてみて、それが改善されるかどうかを確認しますが、作業負荷に対してキャッシュが重要であり、12 MBのチップに戻る必要があるのではないかと思います。
ハイパースレッディングは、せいぜい、L1およびL2キャッシュに直接アクセスすることで、オペレーティングシステムから離れてタスクの切り替えを抽象化し、ダイ上に配置する方法にすぎません。
VMWareを使用したテストでは、ESXiが「実際の」スレッドと「偽の」スレッドの違いを認識するのに十分スマートであるため、HTを無効にしても標準的な負荷では識別可能な違いはなく、高負荷では5％の増加が見られました。 （それ以上のlotがありますが、それは普通の言葉です）。 SQL Server 2005はそれほどスマートではありませんが、最新のオペレーティングシステムと組み合わせると、HTを無効にしてもほとんどメリットがありません。
そうは言っても、L2キャッシュになる可能性が最も高いとロナルドが同意します。キャッシュサイズが33％減少するのはかなりのことであり、SQL Serverを指定するときは常に、常に未加工のクロック速度を超えるキャッシュを使用します。
私の経験に基づくと、HTは、Windows 2008 R2クラスター（SQL Server 2008 R2を実行）上のアクティブノードのI/O操作を永久に実行させていました。興味深い事実は、それが待機統計にも、マイクロソフトのサポートのために実行したpssdiagにも反映されていないことでした。
I/Oの低下に気づいたのは、物理ディスクのOSカウンターを監視するだけでした。サムが指摘したように、私はそれについて書きました ここ および ここ
I/Oの問題が発生せず、CPUバウンドの場合は、次のように開始することをお勧めします。
CPU使用率が最も高い原因となっているプロセスとT-SQLブロックを特定します。私たちの経験では、I/Oの問題を（HTをオフにすることで）修正した後、2008 R2でひどく実行され、2005年には問題なく動作していたコードを特定しました。私はそれについて書きました here 。
高負荷の状態で、Adam Machanicのsp_whoisactiveを実行します。 here からダウンロードできます。計画が非常に悪いために、論理読み取りが過剰になり（クエリごとに2,000万回）、CPU使用率が非常に高くなっていました。私たちのプロセスは、分割されたテーブルとの反準結合を実行していました。
次に推奨するのは、プロファイラーを実行して、CPUとI/Oの論理読み取りの両方が多い一連のT-SQLコードを特定することです。
上記の手順により、問題のあるプロセスを調整し、CPU使用率の85％からほぼゼロにまで引き上げることができました。
幸運を祈ります。私のブログにケースを追加したいので、問題が見つかった場合は遠慮なくご連絡ください。
ありがとう
オスカー
HTの良し悪しを突き止めることは困難です。
実際には、経験と読書に基づくサーバーの負荷パターンに依存します。つまり、パフォーマンスに影響を与えると、ひどく：それ以外の場合は気づきません。
私が読んだ理論は、スレッドがキャッシュを共有するというものでした。つまり、悪条件下では、各スレッドが他のスレッドのキャッシュを上書きする可能性があります。並列処理が少ない場合、または負荷が短いクエリの場合は、影響がない可能性があります。
MAXDOPとプロセッサアフィニティ（SQL Server 2000での最後の実際のDBAロールに戻る）を試してみましたが、決定的なものは見つかりませんでした。
簡単なテストとして、物理コア（小さい番号）のみを使用するようにプロセッサアフィニティを設定し、何が起こるかを確認できます。
ただし、多くてもコアの半分が失われます。最近では、数年前に2対4または4対8でプレイしていたものと比較しても、問題はないかもしれません。現在は、8対16または16対32です。
編集： Slava Oksによるテスト
残念ながら、「ハイパースレッディングをオフにして、それが役立つかどうかを確認する」以上の決定的な答えは得られないと思います。
元のスレッド（質問でリンクしました）でのJonathanからの有益な回答にもかかわらず、調査中の特定のサーバーに対するHTの影響に関する明確な証拠を得ることができませんでした。私の場合、サーバーは既に交換のスケジュールが設定されているので、いわばそれらの交換で「問題を解決」するだけです。
私のアドバイス：
1のサーバーレベルのMAX並列度設定を試してください。 SQLの並列処理はmostとにかく大規模で長時間実行されるクエリに役立ちます。負荷（と私は思います）はとにかく大量の小さなクエリで構成されています。これにより、CXPACKETの待機が完全になくなります。これにより、特定の個々のクエリの実行がわずかに長くなる可能性がありますが、サーバー上のクエリ全体の「スループット」が高くなります。
OLTPサーバー上でこれを行うと良い結果が得られました。他の種類のサーバー（レポートサーバー、処理サーバー、データウェアハウス））では、MAXDOPを高く設定する必要があります。
また、明確にするために、この設定ではSQLがJOINの個々のテーブルごとに複数のスレッドを使用できるため、並列処理を完全に排除しているわけではありません。
この設定の変更はすぐに有効になり、SQLサービスを再起動する必要さえないため、少なくとも試してみる価値はあります。 http://msdn.Microsoft.com/en-us/library/ms181007.aspx
これは、事態がひどくなり始めた場合、すぐに元に戻すことができることを意味します。
BIOSでハイパースレッディングをオフにすると、サーバーを完全に再起動する必要があるため、少し危険です。
記録としては、サーバーのアップグレード後のパフォーマンスも予想外に悪かった。 BIOSとCPUの省電力の問題が原因であることが判明しました。サーバー（HP）のデフォルト設定では、CPU速度のOS制御を無視し、独自のアルゴリズムを使用していました。これをOS制御に変更し、BIOSを更新すると、大幅に改善されました。パフォーマンスが最も低い状態でCPUをロックするBIOSバグがあるというリリースノートがいくつかありました（現在は見つかりません）。