msmq 应该在发送和接收服务器上存储匹配
msmq should storage match on sending and recieving servers
我正在尝试以事务方式向 MSMQ 发送大量消息。遇到存储问题,我们增加了接收机器上的 msmq 存储,发送机器上的存储保持原样(默认 1GB)。我们仍在接收问题,并想确认存储是否应该与发送和接收机器相匹配。
如果您遇到类似问题,请告诉我,理想的解决方案应该是什么。
对于事务性消息,消息存在如下:
- 邮件在发件人的传出队列中可见
- 消息在接收方的目标队列中可见;消息在发件人的传出队列中不可见,等待 ACK 消息
- 消息在接收方的目标队列中可见
因此您会期望有一段时间一条消息在两台计算机上都占用 space。不过,这应该不会持续很长时间,因此您不需要匹配发送方和接收方的存储大小。
应该为 'worst case' 场景设置存储容量。所以假设网络中断。在宣布紧急情况之前,您希望位于发件人的传出队列中的未发送消息和未确认但已发送消息的最大数量是多少。
同样,假设接收器上的应用程序崩溃了,目标队列中有多少未处理的消息构成紧急情况?
存储限制是为了保护您的服务器。
- 它们可以防止硬盘填满(重要)
- 它们防止内核内存耗尽(非常重要 - 参见#4 https://blogs.msdn.microsoft.com/johnbreakwell/2006/09/18/insufficient-resources-run-away-run-away/)
因此存储限制应足够高以适应最坏的情况,但又应足够低以避免耗尽内核内存。
我正在尝试以事务方式向 MSMQ 发送大量消息。遇到存储问题,我们增加了接收机器上的 msmq 存储,发送机器上的存储保持原样(默认 1GB)。我们仍在接收问题,并想确认存储是否应该与发送和接收机器相匹配。 如果您遇到类似问题,请告诉我,理想的解决方案应该是什么。
对于事务性消息,消息存在如下:
- 邮件在发件人的传出队列中可见
- 消息在接收方的目标队列中可见;消息在发件人的传出队列中不可见,等待 ACK 消息
- 消息在接收方的目标队列中可见
因此您会期望有一段时间一条消息在两台计算机上都占用 space。不过,这应该不会持续很长时间,因此您不需要匹配发送方和接收方的存储大小。 应该为 'worst case' 场景设置存储容量。所以假设网络中断。在宣布紧急情况之前,您希望位于发件人的传出队列中的未发送消息和未确认但已发送消息的最大数量是多少。 同样,假设接收器上的应用程序崩溃了,目标队列中有多少未处理的消息构成紧急情况?
存储限制是为了保护您的服务器。
- 它们可以防止硬盘填满(重要)
- 它们防止内核内存耗尽(非常重要 - 参见#4 https://blogs.msdn.microsoft.com/johnbreakwell/2006/09/18/insufficient-resources-run-away-run-away/)
因此存储限制应足够高以适应最坏的情况,但又应足够低以避免耗尽内核内存。