SQL Server Service Broker：如何確定開銷或最大性能？

Question

我們正在嘗試確定我們是否正確使用Service Broker並獲得最高性能。我們一直在調整我們的SB對話和處理，並且已經從3000 /分鐘變成8000 /分鐘，但是CPU保持恆定在100％。此外，在某些日子裏，SB隊列保持空白，但在類似流量的日子裏，隊列可以備份500k。

該機器是四核（16核），沒有HT，32GB RAM和26GB分配給SQL Server，啓用AWE。

SQL Server 2008 SP1（無CU）企業版。 Microsoft Windows Server 2008（SP1） - 10.0.2531.0（X64）Mar 29 2009 10:11:52 Copyright（c）1988-2008 Windows NT 6.1（Build 7600：）上的Microsoft Corporation企業版（64位）

消息被插入到服務代理隊列中，該隊列抽取消息組並通過CLR運行它，CLR解析XML（不是簡單的解析，唉）並插入到表中。 CLR比我們的T-SQL代碼快得多。

我們每個調度

我們夜間運行統計/索引維護平均35個可運行任務。

我們已經設置了服務器MAXDOP = 1來嘗試和幫助性能。

我們已將tempdb文件的數量增加到64個，以避免SGAM爭用，它與TF1118結合似乎已停止TEMPDB爭用。

查看sys.dm_os_waiting_tasks，我們通常在THREADPOOL上等待大約60個任務，其他類型上只有少數任務。

我們的信號等待率爲70％（資源等待= 30％）。

我們已驗證TokenAndUserPermCache保持在20mb以下。

查看sys.dm_os_latch_stats，我們在1分鐘內看到40-200k BUFFER鎖存器，這些鎖存器大多位於sysdesend和用於處理對話框的用戶表中。

我們也看到高SOS_SCHEDULER_WAIT，它也表示CPU壓力。但是，是因爲CLR非常繁忙，還是因爲Service Broker的開銷？我會很樂意提供代碼 - 讓我知道我需要在這裏發佈。

在此先感謝。

Answer 1

1. 您是否僅將SSB用作本地排隊/處理機制，或者是否存在涉及的任何遠程消息傳遞（x-machine傳輸）？
2. 有多少個隊列？
3. 是否涉及激活，我想是的，有多少個max_queue_readers？
4. 任何你可以配合500k尖峯？他們需要多長時間才能流失？

在黑暗中的一些鏡頭：

• 如果你看到周圍的緩衝sysdesend /閂鎖爭sysderecv你可以試試這個：Service Broker Whitepaper on MSDN: the 150 trick。請參閱Dealing with Large Queues。 Skipped Ghost Records/sec是否脫離圖表？

〜60任務等待工人16個CPU的機器上...我woudl通常認爲OK，但對於一個致力於SSB加工機是有點怪，因爲這樣的機器往往有一些長時間運行的任務（激活的作業）而不是許多短時間運行的作業，所以他們不傾向於顯示THREADPOOL等待。