ホールドホールドホールドホールドオン
パフォーマンスとライセンスの側面は興味深いものですが、ワークロードの考慮すべき唯一の側面ではありません。
プロセッサの選択に影響を与える可能性があるのは、ワーカースレッドです。
ワーカースレッド？
うん、バディ！それらは、SQL Serverがクエリを実行し、物事を形に保つために必要なすべてのバックグラウンド処理を行うために使用するものです。
ワーカースレッドが不足すると、THREADPOOLの待機が発生します
スレッドプール？
スレッドプール。これは、RESOURCE_SEMAPHOREおよびRESOURCE_SEMAPHORE_QUERY_COMPILEとともに、サーバー上で行うことができる最も厄介な待機の1つです。しかし、これらはメモリ待機であり、これはCPUの問題です。
なぜこれが機敏な奇策であるかに戻ってください。
SQL Serverがワーカースレッドを計算する方法は次のとおりです。
コアカウントを2倍にしてもMax Worker Threadsが2倍にならないことに注目してください。1コアでも4コアと同じ数になりますか？方程式は次のとおりです。512 + ((logical CPUs - 4) * 16)
コアカウントが上がると、クロック速度は通常1世代または2世代前に急降下するため、これは残念です。
Intelチップの最近のラインを見てみると、同様の傾向が見られます。
必要なスレッド数を知るにはどうすればよいですか？
これは次のことに大きく依存します。
- ユーザー数
- 並列クエリの数
- シリアルクエリの数
- データベースの数とデータの同期（ミラーリング、AG、ログ配布のバックアップ）
- MAXDOPおよびCTFPをデフォルトのままにする場合
今日それらを使い果たしていないなら、あなたはおそらく大丈夫です。
しかし、あなたがどのようにしているかはどうやってわかりますか？
良い質問があり、そして偉大な質問があり、そしてレムはあなたに何か、教えてGREAT質問を。
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で、空気を切らしているワークロードには十分すぎることを保証していると聞いたことがありますか？
残念ながら、そのような問題を解決するために必要なクエリとインデックスのチューニングの種類は、質問の範囲を超えています。
お役に立てれば！