在我驻扎的新公司，我注意到当我们重新启动服务器时，MSMQ 服务需要花很长时间才能启动。它会自动启动，并且开始状态为非常很长一段时间——我们处理的是小时，而不是分钟（此刻我已经过去了 67 分钟，但还没有完成）！
我使用 MSMQ 的经历就像企鹅飞行一样——我见过，但从未亲自做过，所以我无法判断如此巨大的时间消耗是否合理。但是，感觉不对劲，我感觉这背后有些蹊跷。
我得到的解释是“一直都是这样“。因此，我们仍然应该使用火而不是电来获得光亮……我并不是说这里的人错了。我只是想进一步调查它是“新鲜血液”。我可以补充说，这是一种非常不耐烦的血液。
我的 google-fu 没有给我带来太多有用的信息（主要是如果它在操作阶段根本不起作用或工作不令人满意该怎么办）。事件日志没有显示任何信息，其他服务都是之后手动启动的（默认服务除外）。启动时似乎一直很慢，但其他情况并非如此。队列已清空，服务器的行为或多或少与正常人一样。我们的硬盘空间充足。
因此，这个问题是双重的。
- MSMQ 如此长的启动期是否可以接受且预期？
- 如果我对这种行为感到不安，我应该进一步调查什么？
系统如下。
- Windows Server 2008 R2 标准版 SP1
- 64 位，8 GB，Xeon 2.4GHz（2 个内核）
答案1
调查一下。常规服务器重启需要 90 分钟，这很痛苦。如果您需要高可用性，这意味着您需要在一个节点上停留 1.5 小时才能重新启动（在修补期间经常发生这种情况）。这意味着从技术上讲，您需要 3-4 个节点才能实现高可用性。这里有些非常奇怪。我个人不会接受这一点。
当服务器崩溃时，我可以理解这一点。如果必须回滚事务日志，则可能需要很长时间。但是 MSMQ 无法正常处理产生数 GB 的事务，并且 - 重新启动不应导致此处出现过多的操作。
答案2
您一定有很多消息。MSMQ 需要很长时间才能将所有消息映射到内存中。您可能已经检查过您使用的队列是否为空，但这些队列并不是问题所在。通常是日志和系统队列。快速检查 system32\MSMQ\storage 文件夹 - 它将包含大量 4MB 文件。可能有 1,000 个。如果是这样，请检查它们以哪个字母开头。J 代表日志，P 代表持久性。然后使用性能监视器查看所有 MSMQ 对象，而不仅仅是您用于应用程序的队列。如果您有 J*.MQ 文件，也请查看日志队列。您最终会发现队列囤积了消息。我能想到不启动缓慢的其他原因。