ハイパースレッディングを無効にする必要がありますか
[〜＃〜]背景[〜＃〜]最近、SQL Sentryを使用しているかなり長いCXPacket待機時間を調べています。プロセッサのアクティビティをかなり注意深く監視します。
その結果、私が気づいたことの1つは、 context Switchingに大きなスパイクがあることです。 以下は5分のサンプルですが、このパターンは1日を通して非常によく見られます。
あなたが見ることができるように、それはかなり定期的に急上昇します。これについての私の理解は、これがCPUプレッシャーの結果であると私に信じさせるようになります。しかし、その間、かろうじて60％を超えます。
いくつかの調査の後、これは私がこれがハイパースレッディングの結果として起こっていると信じるようになりました。 ハイパースレッディングの危険性のいくつかを以前に読んだことは知っています。 しかし、それはかなり前に書かれたものです。
長い話を短くします。ハイパースレッディングは、コンテキストの切り替えにおけるこのスパイクの原因である可能性がありますか？コンテキストの切り替えが並列クエリに悪影響を及ぼしている可能性はありますか？私の環境ではハイパースレッディングを無効にする必要がありますか？
[〜＃〜] update [〜＃〜]私の環境ではこの特定のことが起こっていますが、その核心にある質問はより普遍的です。高レベルのコンテキスト切り替えは、並列クエリにどの程度影響を与えることができますか？ハイパースレッディングはこの種の問題を引き起こす可能性がありますか？
結局のところ、インターネット上で見つけたほとんどの情報は、ハイパースレッディングとSQL Serverは良い友達ではないことを示唆していますが、ほとんどの場合、その情報は非常に古いものです。
My System構成に関する質問が多かったので、除外できるようにここで説明します。 OSとbioレベルの両方でパフォーマンスの電源設定があります。 Maxdopは8に設定され、並列処理のコストしきい値は25です。32の論理コアと16の物理コアがあります。また、これは大部分がデータウェアハウスの負荷シナリオです。
多くの場合、特定のクエリが並列処理で実行されていることを示しています。サーバーでのCXPACKET待機は、別の問題の症状である可能性がありますが、問題の即時の兆候ではありません。
サーバーがデータウェアハウスまたはレポートタイプのデータベースをホストし、少量のクエリを受信するが大量のデータを処理する場合、並列処理により、これらのクエリの実行にかかる時間を大幅に短縮できます。ただし、対照的に、サーバーがOLTP多くの小さなクエリとトランザクションを含むデータベースをホストしている場合、並列処理はスループットを低下させ、パフォーマンスに悪影響を及ぼす可能性があります。
システム全体のスループットが向上するため、可能な限り、基になる待機タイプを分離してトラブルシューティングすることをお勧めします。繰り返しになりますが、CXPACKETの待機は、ほとんどの場合、実際の問題ではなく、単に問題の症状です。
Sys.dm_os_latch_stats DMVには、インスタンスで発生した特定のラッチ待機に関する情報が含まれます。また、トップラッチ待機の1つがACCESS_METHODS_DATASET_PARENTである場合、CXPACKET、LATCH_ *、およびSOS_SCHEDULER_YIELD待機タイプがトップウェイトとして、システムでの並列処理は、クエリ実行時のボトルネックの原因であり、問題を解決するには、 'max degree of parallelism'のsp_configureオプションの削減が必要になる場合があります。
このTechNet Magazineの記事は古くなっていますが、プロセッサあたり1秒あたり5000を超えている場合は、ハイパースレッディングをオフにしようとしています。
SQL Server CPUパフォーマンスの最適化 Zach Nichter著