Service Brokerを適切に使用しているかどうかを判断し、最大のパフォーマンスを得ようとしています。私たちはSBの会話と処理を調整しており、3000 /分から8000 /分になりましたが、CPUは100％で一定です。さらに、ある日SBキューは空のままですが、同様のトラフィック日にキューは500kまでバックアップできます。SQL Server Service Broker：オーバーヘッドまたは最大のパフォーマンスを決定する方法は？
マシンはクワッドクワッド（16コア）、HTなし、32GB RAM、AWBが有効なSQL Serverに割り当てられた26GBです。
SQL Server 2008 SP1（CUなし）、Enterprise Edition。 Windows NT 6.1（ビルド7600：）のマイクロソフトコーポレーションエンタープライズエディション（64ビット）
のMicrosoft SQL Server 2008（SP1） - 10.0.2531.0（X64）Mar 29 2009 10:11:52メッセージはサービスブローカキューに挿入されます。サービスブローカキューはメッセージのグループを取得し、XMLを解析して（単純な解析ではなく）CLRを介して実行し、テーブルに挿入します。 CLRはT-SQLコードよりもかなり高速です。
私たちは毎晩統計/索引のメンテナンスを実行するスケジューラ
あたり35の実行可能なタスクの平均を持っています。
パフォーマンスを向上させるために、サーバーMAXDOP = 1を設定しました。
TFAMの競合を避けるために、TF1118のTEMPDBファイルの数を64に引き上げました。これは、TF1118と組み合わせてTEMPDBの競合を停止させたようです。
sys.dm_os_waiting_tasksを見ると、通常、〜60個のタスクがTHREADPOOLで待機していますが、その他の種類はほんの一握りです。
信号待ちは70％（リソース待機= 30％）です。
TokenAndUserPermCacheが20MB未満であることを確認しました。
sys.dm_os_latch_statsを見ると、1分で40~200kのBUFFERラッチが表示されます。これは主にsysdesend上にあり、Dialogsを処理するために使用するユーザーテーブルです。
また、SOS_SCHEDULER_WAITの値が高いこともわかります。これはCPUの負荷も示しています。しかし、CLRが忙しそうに忙しくなったり、Service Brokerのオーバーヘッドが原因です。私は喜んでコードを提供します - ここに投稿する必要があることを教えてください。
ありがとうございます。
これはserverfault.comに再ポストすることを検討したいと思うでしょう。それは管理者のためのサイトです。あなたはまだここで答えを得るかもしれませんが、StackOverflowは通常、（SQLクエリのように）コーディングに合わせて調整されています。 – JNK