本文讲述了Nsb主节点用来控制消息加载的控制队列，虽然对我来说仍然不清楚如何解释这个队列中消息数量的不成比例：https://docs.particular.net/nservicebus/msmq/distributor/
我观察到我之前从未经历过缓慢的Nsb服务的缓慢。由于某些原因，与过去的时间相比，每个主节点都创建了较少的并行线程，并且工作者或主节点配置没有变化，例如要分配的最大线程数。我正在试图弄清楚它是不是想要给工人喂养的主节点，还是工人不想要更多的工作。
我看到控制队列中的消息数量从15跳到40，而存储只有5-8。我应该将其解释为工作人员准备工作，而分销商不能向他们发送更多消息吗？感谢
答案 0 :(得分：2)
只要分发者分发消息，控件和storage queue中的数字就会上下跳动。进入control queue的消息将立即从该队列弹出storage queue。进入分发服务器primary queue的消息将立即导致storage queue的第一条消息被弹出。
很难解释正在运行的分发服务器队列中的消息数量，因为当您使用计算机管理或队列资源管理器查看数字时，它们将会发生变化。
极端的情况是：
<强> 1。分发服务器的主输入队列中没有消息，任何工作人员都没有工作。
<强> 2。所有工人都在满负荷工作。无法承担更多工作。
在一个正在运行的系统中，它可以是这两个极端之间的任何东西，所以，遗憾的是，很难从control和storage queue的快照中说出很多。
一些问题排查提示：
如果storage queue为空，则经销商无法分发更多工作。它不知道在哪里发送它。如果所有工作人员都被完全占用，则会发生这种情况，因为他们不会将任何准备好的消息发送回control queue，直到他们完成处理消息为止。
如果storage queue与所有工作人员的工作线程总数相比一直很小，那么您将接近工作人员的总最大容量。
我建议你开始查看工人的日志，看看他们正在做的工作是否需要比平时更长的时间。数据库/第三方集成速度较慢？
要检查的另一件事是，是否有任何IO-heavy添加到托管分发服务器的计算机上。如果分发服务器已经以接近最大容量运行，则添加额外的IO可能会降低盒子上的MSMQ速度，从而降低吞吐量。