ハイパースレッディングを無効にすると、SQL Serverインストールのパフォーマンスが向上します

関連：SQL Serverとハイパースレッディングに関する現在の知恵

最近では、当社からのWindows 2008 R2データベースサーバをアップグレードしX5470にX5560。理論的には、どちらの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
-------------------------------------------------- ---------- -------------------- -------------------- -------------------- --------------------
XE_TIMER_EVENT 115166 2799125790 30165 2799125065
REQUEST_FOR_DEADLOCK_SEARCH 559393 2799053973 5180 2799053973
SOS_SCHEDULER_YIELD 152289883 189948844 960 189756877
CXPACKET 234638389 2383701040 141334 118796827
SLEEP_TASK 170743505 1525669557 1406 76485386
LATCH_EX 97301008 810738519 1107 55093884
LOGMGR_QUEUE 16525384 2798527632 20751319 4083713
WRITELOG 16850119 18328365 1193 2367880
PAGELATCH_EX 13254618 8524515 11263 1670113
ASYNC_NETWORK_IO 23954146 6981220 7110 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
PAGEIOLATCH_SH 19018.53 2.26 94.37
FT_IFTSHC_MUTEX 14306.05 1.70 96.07

これは、並列処理を伴うクエリの同期に膨大な時間がかかることを示しています（高CXPACKET）。さらに、逸話的にこれらの問題クエリの多くは複数のコアで実行されています（コードのどこにもMAXDOPヒントはありません）

サーバーに1日以上負荷がかかっていません。クエリの実行には大きなばらつきがあります。通常、多くのクエリは以前のDBサーバーよりも遅く、CPUが非常に高いようです。

ハイパースレッディングを無効にすると、CPU使用量が削減され、スループットが向上しますか？

私はまだ、元の答えに従って、特定のワークロードをテストすることが唯一の方法であると感じています。実稼働システムを調整しようとするとき、それは理想的な答えではありません（したがって、パフォーマンスと可用性の両方が本当に重要なシステムで同一のテストベッドを取得できるかどうかを尋ねます）が、それは私が本当に快適な唯一のものですと。

ハイパースレッディングが一般的に物事を傷つけたり改善したりするかどうかの理論について話すことができます（サーバーでの助けよりも傷つきやすいと思うので、「一般的な」展開の場合はおそらく無効にします）。特定のケースで違いが生じるかどうかを確認する唯一の方法は、それを試してみることです。

私はそれに賛成だ

• で最高の勧告は、「ワークロードにハイパースレッディングを試してみて、何が起こるか見て」です。入力中にこれを実行していますが、うまくありません！
• 最も安全であるため、常にハイパースレッディングを無効にして起動する必要があります。

次の2つのことを調整する必要があるようです。

1. MAXDOP（最大並列度）。私が読んだすべては、これを無制限にすることはおそらく悪い考えであることを示しており、Microsoftのドキュメントには次のように書かれています：

   このオプション[MAXDOP]を[8]より大きい値に設定すると、多くの場合、不要なリソース消費とパフォーマンスの低下が発生します。

   8一般的に推奨されていないものよりも高いものは..ですので、今のところ設定4します。最初はゼロ（無制限）でした。

2. 並列処理のコストしきい値。どうやらのデフォルト5ここでは、私が見つけたいくつかのSQL MVPの記事によると、かなり低いデフォルトと見なされている-私たちはできるチューンそれをしても、スケジューラによって試行されたどのくらいの並列処理削減します。

しかし、正直なところ、これらは回避策のように感じます。ワークロード（フルテキストインデックスが多い）の真の解決策は、HTを無効にすることだと思います。

Anandtechは、純粋な読み込みの負荷では少し痛く、書き込みの重い負荷では少し勝つことを発見しました。-5％をはるかに下回るヒット、または15％をはるかに上回る勝利をもたらすと思うようにするものは見ていません。Atomを使用すると、大きな勝利になりますが、それは非常に奇妙なCPUです。

変更したのはCPUだけですか？12MBのキャッシュと4つのスレッド、つまりスレッドごとに3MBのキャッシュから、8MBのキャッシュと8つのスレッド、つまりスレッドごとに1MBになりました。今、それは単純化しすぎていますが、それはあなたを殺しているものだと思います、あなたはキャッシュでクエリを実行するのに使用し、1MB以上3MB未満を必要とするのでRAMから実行します。HTをオフにするとおそらく役立つでしょうが、古いCPUに戻ります。HTをオフにすると、スレッドごとに2MBが得られますが、その分だけワークロードがスラッシングすると、役に立ちません。古い12MBキャッシュCPUは、ワークロードに対して非常に高速である可能性があります。

HTをオフにしてみて、それが改善されるかどうかを確認しますが、キャッシュが作業負荷にとって重要であると思われるため、12 MBのチップに戻る必要があります。

ハイパースレッディングは、せいぜい、オペレーティングシステムからタスクスイッチングを抽象化し、L1およびL2キャッシュに直接アクセスしてそれをダイ上に配置する方法であり、タスクスイッチングの高速化を実現します。

VMWareでのテストでは、HTを無効にしても、標準負荷では識別可能な違いはなく、重負荷では5％増加しました。これは、ESXiが「実際の」スレッドと「偽の」スレッド（ありますたくさんのより多くのそれに比べて、それはlaymensの用語ではあります）。SQL Server 2005はそれほどスマートではありませんが、最新のオペレーティングシステムと組み合わせると、HTを無効にする利点はほとんどありません。

そうは言っても、LonaldがL2キャッシュになる可能性が最も高いことに同意します。キャッシュサイズの33％の低下は相当なものであり、SQL Serverを指定するときは常に、常に生のクロック速度を超えるキャッシュを使用します。

私の経験に基づいて、HTはWindows 2008 R2クラスター（SQL Server 2008 R2を実行している）上のアクティブノードでI / O操作を永久に実行させていました。興味深い事実は、待機統計にも、マイクロソフトのサポートのために実行したpssdiagにも反映されていないことです。

I / Oが低いことに気付いたのは、物理ディスクのOSカウンターを見るだけでした。サムが指摘したように、私はこことここでそれについて書きました

I / Oの問題が発生せず、CPUに縛られている場合は、この方法から始めることをお勧めします。

どのプロセスとT-SQLブロックが最もCPU使用率が高いかを特定します。私たちの経験では、I / Oの問題を（HTをオフにして）修正した後、2008 R2でひどく動作し、2005年に正常に動作するコードを特定しました。

高負荷の状態で、Adam Machanicのsp_whoisactiveを実行します。こちらからダウンロードできます。本当に悪い計画による論理読み取りの過剰量（クエリごとに2000万回）により、非常に高いCPU使用率が発生していました。私たちのプロセスは、パーティション化されたテーブルとの反準結合を実行していました。

次の推奨事項は、プロファイラーを実行して、CPUとI / Oの両方の論理読み取りが多いT-SQLコードのセットを識別することです。

上記の手順により、問題のあるプロセスを調整し、85％の持続CPU使用率からほぼゼロに移行することができました。

幸運を祈ります。修正を見つけた場合は、ブログにケースを追加したいので、気軽に連絡してください。

ありがとう

オスカー

HTが良いか悪いかを特定するのは困難です。

実際には、経験と読み取りに基づくサーバーの負荷パターンに依存します。つまり、パフォーマンスに影響を与えると、ひどく悪影響を及ぼします。それ以外の場合は気づきません。

私が読んだ理論は、スレッドがキャッシュを共有するというものでした。これは、悪条件下では、各スレッドが他のスレッドのキャッシュを上書きできることを意味します。並列性があまりない場合、または負荷が短いクエリの数が多い場合は、影響はありません。

私はMAXDOPとプロセッサアフィニティ（SQL Server 2000での最後の実際のDBAの役割に戻って）を試しましたが、決定的なものを見つけることはできませんでした。

簡単なテストとして、物理コア（低い数値）のみを使用するようにプロセッサアフィニティを設定し、何が起こるかを確認できます。

ただし、多くてもコアの半分が失われます。最近では、2対4または4対8だった数年前に遊んでいたものと比較して重要ではないかもしれません。今では8対16または16対32です。

編集：Slava Oksによるテスト

残念ながら、「ハイパースレッディングをオフにして、それが役立つかどうかを確認する」よりも決定的な答えを得るとは思わない。

私の元のスレッドでジョナサンからの有益な回答にもかかわらず（質問でリンクしました）、私が調査している特定のサーバーに対するHTの影響について明確な証拠を得ることができませんでした。私の場合、サーバーはすでに交換が予定されていたので、いわばそれらの交換が「問題を処理する」ようにするだけです。

私のアドバイス：

サーバーレベルのMAX並列度設定1を試してください。SQLの並列処理は、とにかく大きくて実行時間の長いクエリに最も役立ち、負荷（と思われる）はとにかく非常に多数の小さなクエリで構成されます。これにより、CXPACKETの待機が完全に排除されます。これにより、特定の個々のクエリの実行がわずかに長くなる可能性がありますが、サーバー上のクエリ全体の「スループット」を増やすことができます。

OLTPサーバーでこれを行うと良い結果が得られました。他の種類のサーバー（レポートサーバー、処理サーバー、データウェアハウジング）では、MAXDOPをより高く設定する必要があります。

明確にするために、この設定では、JOINの個々のテーブルごとに複数のスレッドをSQLで使用できるため、並列処理を完全に排除することはできません。

この設定変更はすぐに有効になり、SQLサービスを再起動する必要さえないため、少なくとも試してみる価値があります。http：//msdn.microsoft.com/en-us/library/ms181007.aspx
これは、切り替えることができることを意味します物事が地獄に行き始めた場合、すぐに戻ってきます。

BIOSでハイパースレッディングをオフにするには、サーバーを完全に再起動する必要があるため、少し危険です。

記録のために、サーバーのアップグレード後、予想外にパフォーマンスが低下しました。BIOSとCPUの省電力の問題が原因であることが判明しました。サーバー（HP）のデフォルト設定は、CPU速度のOS制御を無視し、独自のアルゴリズムを使用することでした。これをOS制御に変更し、BIOSを更新すると、大幅に改善されました。最低のパフォーマンス状態でCPUをロックしていたBIOSのバグがあったというリリースノートがいくつかありました（現在は見つかりません）。

https://serverfault.com/a/196329/6390