CPUクロック速度とCPUコア数-より高いGHz、またはSQL Serverのコア数が多いですか？
VMware内のSQL Server 2016ノードの仮想クラスター用に一連の物理サーバーをプロビジョニングし始めています。 Enterprise Editionライセンスを利用します。
6つのノードをセットアップする予定ですが、CPUクロック速度とCPUコア数の関係に関して、物理サーバーをプロビジョニングする理想的な方法については少し議論があります。
これは、トランザクションの量と、他のソフトウェア固有の要因の中で保存されているデータベースの数に大きく依存していることは知っていますが、一般的な経験則が推奨されますか？
たとえば、デュアル8コア、3.2 GHz物理サーバー（16コア）は、デュアル16コア、2.6 GHzサーバー（32コア）よりも優先されますか？
このタイプのトピックをさらに掘り下げているホワイトペーパーを見つけた人はいますか？
一般的な経験則では、コア数をできるだけ少なくし、プロセッサ速度をできるだけ高くします。これに関するライセンスの計算は、高価なエディションのコアあたり約7,500米ドルという点を証明しています。
適切なハードウェアを購入することで、ライセンスコストを削減できます。 Glenn Berryによる SQL Serverのプロセッサ選択 を参照してください。 SQL Serverのプロセッサを選択する方法に関する優れたリソースです。
SQL Serverのコアごとのライセンス構造を考慮すると、OLTPまたはアナリティクスなど）に関係なく、ワークロードの種類に関係なく、常に利用可能な最速のプロセッサ速度を使用することが理にかなっています。必要に応じてコア数を増やしますが、コア速度を下げてコア数を増やすことは決してありません。
言い換えると、16 x 2.2Ghzプロセッサが8 x 4.5Ghzプロセッサと同じであるとは考えないでください。 4.5Ghzプロセッサよりも2.2Ghzプロセッサを使用した場合のコスト削減は、最大で約10,000米ドル（通常のXeonベースの2プロセッサマシンの場合）です。 SQL Server Enterprise Editionで8コアから16コアにジャンプすると、ライセンス料が60,000米ドルを超える可能性があります。言い換えれば、ハードウェアコストで$ 10,000を節約できるかもしれませんが、ライセンスで追加の$ 50,000を失うことになります。
大量の並列処理が必要で、タスクに32コアが必要であると判断した場合、最速のコアを使用すると、処理時間を短縮できます。誰もあなたのために失敗することはありません。
それでも、1つのCPUまたは複数のCPUを選択する場合は、常に1つ以上を選択してください。 SQL Server（または任意のDBMS）を単一のCPUで実行すると、同時操作の機能が大幅に制限されるため、あらゆる種類の問題が発生する可能性があります。
保留中保留中保留中
パフォーマンスとライセンスの側面は興味深いものですが、考慮すべきワークロードの唯一の側面ではありません。
プロセッサの選択に影響を与える可能性のあるものの1つは、ワーカースレッドです。
ワーカースレッド？
うんバディ！これらは、SQL Serverがクエリを実行し、正常な状態を保つために必要なすべてのバックグラウンド処理を実行するために使用するものです。
ワーカースレッドが不足すると、 [〜＃〜] threadpool [〜＃〜] 待機します
THREADPOOL？
スレッドプール。これは、 RESOURCE_SEMAPHOREおよびRESOURCE_SEMAPHORE_QUERY_COMPILE とともに、サーバーで発生する可能性がある最も厄介な待機の1つです。しかし、それらはメモリ待機であり、これはCPUの質問です。
なぜこれがウィッグ・ワックなのかを考えてみましょう。
これはSQL Serverがワーカースレッドを計算する方法です ：
コア数を2倍にしても最大ワーカースレッドが2倍にならず、1コアでも4コアと同じ数になることに注意してください。方程式は次のとおりです：512 + ((logical CPUs - 4) * 16)
コア数が増えると、通常、クロック速度が1世代か2世代遅れるので、それは残念です。
Intelチップの最近の行 を見ると、同様の傾向が示されます。
必要なスレッドの数を知る方法は？
これは次の要素に大きく依存します。
- ユーザー数
- 並列クエリの数
- シリアルクエリの数
- データベース数とデータ同期（ミラーリング、AG、ログ配布のバックアップ）
- MAXDOPとCTFPをデフォルトのままにした場合
今日それらを使い果たしていなければ、おそらく大丈夫です。
しかし、あなたがあなたであるかどうかはどうやってわかりますか？
良い質問があり、素晴らしい質問があり、そしてlemmeが何かを伝えます、それは素晴らしい質問です。
THREADPOOLは 接続の問題 として現れる可能性があり、エラーログに スレッドを生成 できないというメッセージが表示される場合があります。
sp_Blitzまたはsp_BlitzFirst （完全な開示、私はこのプロジェクトに貢献しています）などの無料のツールを使用して、サーバーの待機統計を確認することもできます。
EXEC sp_Blitz
EXEC sp_BlitzFirst @SinceStartup = 1
Max Worker Threadsだけを増やすことはできませんか？
MWTを増やすと、SOS_SCHEDULER_YIELD待機します。
それは世界の終わりではありませんが、教師のクラスに子供たちが叫んでいるバンチャを追加するようなものだと考えてください。
突然、子供一人一人が注意を引くのが難しくなります。
プロセス 4msの量を使い果たす の場合、CPUに到達するために待機しているスレッドの前にスレッドが存在する可能性があります。
パフォーマンスはほぼ同じように感じるかもしれません。
ワーカースレッドの数を減らすにはどうすればよいですか？
あなたは[名詞]の残酷な[名詞]です。住宅ローン！夢！
しかし、申し分なく、収益を尊重する必要があります。あなたはボスです。
最も簡単な開始点は、MAXDOPや並列処理のコストしきい値などの設定をデフォルトから変更することです。
これらの設定方法について質問がある場合は、こちらをご覧ください。
その後、あなたの仕事はかなり難しくなります。これらすべてのスレッドを使用しているものを理解する必要があります。あなたは時々あなたの待機統計を見ることによってそれを行うことができます。
より具体的には、並列処理の待機時間が長い場合（CXPACKET）およびロックの待機時間が多い場合（LCK_）の場合、並列クエリを含む長いブロッキングチェーンに遭遇している可能性があります。
悪臭って知ってる？これらの並列クエリはすべて、ロックを取得するために待機していますが、割り当てられたスレッドを返しません。
4つのコアVMは、管理者が、ワークロードが空気で息を切らすのに十分以上であることを保証したと確信していることを聞いていますね？
残念ながら、その問題を解決するために実行する必要があるクエリとインデックスのチューニングの種類は、質問の範囲を超えています。
お役に立てれば！
SQL ServerのほとんどのワークロードはOLTP）です。これは、シリアル操作であるため、クロック速度が高いほどメリットがあります。
超並列システム用に特別に設計しているのでない限り、クロック速度は常に勝ります。エッジケースは存在しますが、それは95％の確率で答えです。最終的にコストが安くなるということもいいことです。