MSMQ QMThreadNo 和 CleanupInterval答案

【问题标题】：MSMQ QMThreadNo and CleanupIntervalMSMQ QMThreadNo 和 CleanupInterval
【发布时间】：2012-03-27 20:12:54
【问题描述】：

我有一个使用 MSMQ 和 NServiceBus 进行消息传递的客户端-服务器应用程序。在最近的一些测试中，客户端在一段时间内处于非活动状态，并且发现了 MSMQ 的意外行为：

MSMQ 具有用于处理队列的默认线程数（在注册表中设置为 QMThreadNo）。当队列处于休眠状态时状态很长一段时间，它们积累了大量的消息。这些大队列保留了有限数量的 MSMQ 拥有的线程比平时更长，因此确实需要更长的时间来处理实际处于活动状态的队列。
- 可以将注册表项设置为更高的线程数。
客户端在一段时间内未发送/接收消息时间（在注册表中设置为 CleanupInterval）将更改为 “非活动”状态，最终他们的队列将被删除，直到消息从该客户端发送，强制重新创建排队。
- CleanupInterval 可以从默认的 5 分钟更改为更长的时间。

以前有人遇到过这些问题吗？如果有，有哪些可能的解决方案？

【问题讨论】：

【解决方案1】：

您需要区分传出队列或目标队列。

"当队列长时间处于休眠状态时时间，他们积累了大量的消息。这些大排长龙保持 MSMQ 拥有的有限线程数超过通常，因此确实需要更长的时间来处理实际活跃。”

MSMQ 有一个用于传出队列的线程池。 MSMQ 将尝试将传出队列连接到目标并传递消息。例如，如果您有 1,000 个传出队列，那么 MSMQ 将需要一些时间来循环遍历所有队列。这与目标队列无关。

我不太明白传出队列中的消息数量将如何影响线程使用率。在任何时候，特定队列上只会有一个线程在使用。

一个活动队列有一个线程 - 否则它不会是活动的。我假设我们在这里讨论的是计算机管理中的队列状态。

在一段时间内未发送/接收消息的客户端时间（在注册表中设置为 CleanupInterval）将更改为 “非活动”状态，最终他们的队列将被删除，直到消息从该客户端发送，强制重新创建排队。

同样，这只是传出队列。传出队列由 MSMQ 按需动态创建。如果它们为空，则在 CleanupInterval 之后将它们删除。这是完全正常的，也是 MSMQ 释放资源的方式。

与任何产品一样，MSMQ 可能需要优化以满足您的需求。如果您想更改注册表值，请继续。

干杯
约翰·布雷克韦尔

【讨论】：

*感谢您的回复，约翰。为了消除歧义，我们有一个部分连接的客户端/服务器应用程序，它需要实时消息传递。我们在您的一些文章中读到，MSMQ 最初不是为实时设计的，但可以配置为这样做。我们的问题是客户端上的传出队列设置为“已连接”。然而，服务器上的传出队列设置为“非活动”长达 30 分钟，这对于我们的“实时”系统来说效率很低。在这段时间之后，服务器上的传出队列设置回“已连接”并且消息再次正常流动。
我们已将 QMThreadNo 修改为 3000，但没有注意到从非活动到已连接的进度变化。我们还将 WaitTime 修改为 5000，希望它可以减少处理不同线程之间的时间。
所以您已经证明这不是线程问题。除非您有很多很多的传出队列，否则我不会期望它。
这是服务器上的传出队列从“非活动”变为“已连接”所需的时间，这就是问题所在。目前服务器大约有。 40 个传出队列，我们注意到延迟时间长达 10 分钟。
如果您有足够数量的线程（3,000 应该足够了！），那么要么该值未正确输入注册表（因此被忽略），要么存在网络级连接问题.每个传出队列应在其中创建消息后最多连接 5 秒（因为您已将 WaitTime 设置为 5,000 毫秒）。我建议查看网络跟踪以查看是否存在连接问题（名称解析延迟总是一个好的问题）。