在我刚刚进驻的新公司，我注意到当我们重新启动服务器时，启动MSMQ服务需要一点时间。 它会自动启动，并处于启动状态，这个时间非常漫长 – 我们正在触摸几小时，而不是几分钟（这一刻我已经过了67分钟，还没有完成）！
我和MSMQ的经历就像企鹅的飞行一样 – 从来没有见过，所以我不能真正判断这么大的时间消耗的合理性。 然而，这感觉不对，我觉得这背后有些可疑之处。
我得到的解释是“ 一直都是这样的 ”。 出于这个原因，我们仍然应该使用火而不是电来照亮…我不是说这里的人是错的。 我只是想进一步调查它是“新鲜的血液”。 一个非常不耐烦的血，我可以补充说。
我的谷歌产品没有多less，我从中得到了什么（大部分是做什么，如果它不工作，或在工作阶段工作不满意）。 事件日志什么也不说，其他的服务在之后手动启动（除了默认的）。 开始时的缓慢似乎是一致的，但不是这样。 队列被清空，服务器的行为或多或less像普通人一样。 我们有丰富的硬盘空间。
所以，这个问题是双重的。
系统如下。
调查。 90分钟的常规服务器重新启动是痛苦的。 如果您需要高可用性，这意味着您在一个节点上运行1.5小时，即“重启”（在修补过程中经常发生）。 这意味着您在技术上需要3-4个节点才能获得高可用性。 这里有一些很奇怪的东西。 我个人不会接受的。
我可以理解，当服务器崩溃。 如果事务日志必须回滚，可以采用AGES。 但是MSMQ不能正常处理产生许多千兆字节的事务，并且重启过程不应该导致过多的操作。
你必须有很多的消息。 MSMQ花费时间将所有消息映射到内存中。 您可能已经检查了您使用的队列是空的，但这些队列不会是问题所在。 通常是日志和系统队列。 快速检查system32 \ MSMQ \ storage文件夹 – 它将包含大量4MB文件。 可能会有一千个。 如果是这样，请检查他们开头的字母。 J是期刊，P是持久性的。 然后使用性能监视器查看所有MSMQ对象，而不仅仅是用于应用程序的队列。 如果您有J * .MQ文件，请查看日记队列。 你最终会发现囤积消息的队列。 我可以想象没有其他的原因，你慢启动。