2

我们正在尝试确定我们是否正确使用 Service Broker 并从中获得最大性能。我们一直在调整我们的 SB 对话和处理，从 3000/分钟到 8000/分钟，但 CPU 一直保持在 100%。此外，在某些日子 SB 队列保持为空，但在类似流量的日子，队列可以备份 500k。

该机器是四核（16 核），没有 HT，32gb RAM 和 26gb 分配给 SQL Server，启用了 AWE。

SQL Server 2008 SP1（无 CU），企业版。Microsoft SQL Server 2008 (SP1) - 10.0.2531.0 (X64) 2009 年 3 月 29 日 10:11:52 版权所有 (c) 1988-2008 Microsoft Corporation Enterprise Edition (64-bit) o​​n Windows NT 6.1 (Build 7600: )

消息被插入到服务代理队列中，该队列提取消息组并通过 CLR 运行它们，CLR 解析 XML（不是简单的解析，唉）并插入到表中。CLR 比我们的 T-SQL 代码快得多。

每个调度程序平均有 35 个可运行任务

我们每晚进行统计/索引维护。

我们已将服务器 MAXDOP = 1 设置为尝试提高性能。

我们将 tempdb 文件的数量增加到 64 个以避免 SGAM 争用，结合 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 开销？我很乐意提供代码 - 让我知道我需要在这里发布什么。

提前致谢。

4

1 回答 1

2
  1. 您是否仅将 SSB 用作本地排队/处理机制，或者是否涉及任何远程消息传递（x 机传输）？
  2. 排了多少队？
  3. 是否涉及激活，我假设是的，有多少 max_queue_readers？
  4. 有什么可以与 500k 尖峰相关的东西吗？他们需要多长时间才能排水？

黑暗中的一些镜头：

在 16 CPU 机器上等待工人的大约 60 个任务……我通常认为可以，但对于专用于 SSB 处理的机器来说有点奇怪，因为这样的机器往往很少有长时间运行的任务（激活的作业）对于许多短期运行的，所以他们不倾向于显示 THREADPOOL 等待。

于 2011-01-06T21:09:06.410 回答