SQL Server：追加のCPUがバッチを遅くする
仮想化環境のWindows 2008R2でSQL Server 2012を実行しています。 VMware Workstation 9とHyper-V 2012R1の両方で以下を確認しましたが、対処方法がわかりません。
仮想マシンに単一のCPUがある場合、実行に約5分かかるバッチがあります。 2から8のどこかで急上昇すると、実行に10分以上かかります。タスクマネージャーを見ると、並列実行とコンテキストの切り替えが多くてもほとんどないことがわかります。タスクマネージャでプロセッサアフィニティを設定してsqlservr.exeを1つのCPUに制限すると、時間が5分に戻ります。
私が実行している特定のバッチは、削除できないカーソルと動的SQLを多用しています。
クエリはプロファイリングされ、最適化されています。統計はすべて最新であり、インデックスが再構築されます。
より良い動作を得るためにSQL Serverにできることはありますか？これは正しくないようです。 VMに追加のCPUリソースを追加して、シリアル化された処理のパフォーマンスを大幅に低下させることなく、必要に応じて使用できるようにしたいと思います。
CPUはi7-4770Kで、ハイパースレッディングが有効な場合と有効でない場合の両方でVT-xが有効になっています。
編集：いくつかの統計-Hyper-Vのルートパーティションから実行すると、1 CPUで4：41、8 CPUで7:30になります。仮想化なしで実行すると、1 CPUで4：11、8 CPUで5:23かかります。
EDIT2：Jon Siegelの推奨により、両方のケースでクエリプランのトレースを取得しました。ループとカーソルのため、クエリプランは長い（50万行）。 2つの間に明らかな違いはなく、使用中に並列処理の兆候は見られません。
さらに、サーバーレベルでMAXDOP = 1を設定すると、1 CPUに制限され、バッチが高速になるという点で、アフィニティ設定と同じ効果があります。
Jonは、回避策として接続ごとにCPUを制限する機能を可能にするSQL 2012 EEのリソースガバナー機能にも気付いた。関連する設定は、リソースプールのAFFINITY SCHEDULERオプションです。
したがって、この時点で要約すると、mutlicore：loop * cursor * exec（ MS-SQL-no-likey）==（仮想化は問題を解決していません）。
クエリやデータが表示されないため、クエリの推測しかできません。おそらくそれは単に並列実行に向いていないだけでしょう。その場合、クエリヒントOPTION（MAXDOP 1）（ORDER BY句の後）を使用して、クエリを強制的に1つのコアのみで実行できます。 。
非仮想化環境でパフォーマンスを分析してみましたか？自然に並列化が容易ではないプロセス（特にが少しでパラメーター化できるプロセス）がCPUコア間でバウンスされることがよくあります（これは、 OSとアプリは、このようなコンテキスト切り替えは比較的コストがかからないと想定しているため、2つのコアの1つを100％ではなく50％消費する、かなり静かなシステムでの単一プロセス。仮想化された環境では、VMMがVMのプロセスの状態を実際のコアの周りに移動し、他のVMの状態をクリア（および適切な場所に格納）する必要があるため、このコンテキストの切り替えは非常にコストがかかる可能性があります。また、高価な二次的影響として、CPUのキャッシュの使用がはるかに少なくなります。また、プロセスが複数のコアを使用している場合、各スライスでVMは、必要なすべてのコアが他の場所からのタスクから解放されるまで待機する必要があるため、並列は実際には並列（または可能な限り近い）であり、仮想化環境が新しいタイミングの問題を引き起こすリスクを軽減します。単一のvCPUの場合、待機待ち時間は1つのコアが解放されるまでです。
時々VMMが明るくなり、これが発生していることを確認し、キャッシュの使用を改善するために1つのVMのプロセスを特定のコアにロックしておくことができますが、これにはシステムのキャッシュ配置の特定の知識が必要です（すべてのコア間でL2が共有されているか、またはコアのペアごとに別々のL2キャッシュがあるなど）-他のVMからの大きな負荷がかかっている場合、他のVMのvCPUへのアクセスに影響を与える可能性があり、VMMの優先順位はoverallパフォーマンスは単一のVMのパフォーマンスではありません。
lt; dr：これは単にvCPUの管理方法であり、SQL Serverが制御できる（またはSQL Serverを介して制御できる）ものではない可能性があります。多くの場合、同時実行性の高いロード（他の多くの操作で実行されているこのプロセスのタイミングをテストしたり、ロックが必要な場合はそれ自体の他のインスタンスと同時にテストしたりしますか？）追加のvCPUare便利ですが、ほとんどの作業が同時実行性が低い場合は、なしの方が良いでしょう。その場合、トレードオフが適切かどうかを確認するために、より広範なベンチマークを行う必要があります。アプリケーション全体にとって価値があります。
それでもlt：この1つのプロセスは奇妙かもしれません、MSSQLが複数のコアを処理する方法とVMMが物理コアの競合を管理して非効率を生成する方法のEdgeケース：vCPUを追加する価値があるかどうかをより広く確認するためのベンチマークあなたのアプリケーションのために。