MSMQ慢队列读取 [英] MSMQ slow queue reading
问题描述
我正在使用一个开源的.Net库，该库在下面使用MSMQ.大约一周或两周后，服务速度会降低(不是准确计时，而是一般猜测).似乎正在发生的情况是，每10秒仅准确读取一次来自MSMQ的消息.通常，它们是即时读取的.因此，它们将在T + 10秒，T + 20秒，T + 30秒等时间进行读取，而与发送消息的时间无关(即有时读取消息需要3秒钟，而其他时候需要9秒钟).
I am using an open source .Net library which uses MSMQ underneath. After about a week or 2, the service slows down (not timed exactly but general guess). It appears that what is happening is messages from MSMQ are only being read exactly once every 10 seconds. Normally, they are read instantly. So they will be read at T+10sec, T+20sec, T+30sec, etc. independent of when the message was sent (i.e. sometimes it takes 3 seconds for the message to be read, other times 9 seconds).
我目前恢复正常的方法只是删除&重新创建队列.因此，问题是，什么会在MSMQ队列中累积而导致这种速度变慢?发生减速时，队列中没有消息.是否有任何高级MSMQ分析工具可以让您更深入地了解队列(与计算机管理相对)?
The current way I get it back to normal is simply deleting & recreating the queues. So the question is, what can build up in MSMQ queues to cause this kind of slow down? There are no messages in the queues when the slowdown occurs. Are there any advanced MSMQ analysis tools that give you a deeper look at the queues (as opposed to Computer Management)?
哦，我忘了提及，将消息写入队列似乎仍然是瞬时的.它只是在阅读显示此行为的消息.
Oh, I forgot to mention, writing the messages to the queue still appears to be instantaneous. It is just reading the messages which shows this behavior.
编辑:后续问题@ 此处，它会更详细，更集中.
Follow up question @ here which is a bit more detailed and more focused.
推荐答案
自从我做MSMQ东西以来已经有一段时间了，所以请忍受(宽容)我的旧大脑记忆. 我想到了一些问题:
It has been a while since I did MSMQ stuff so bear with me (be tolerant) of my old brain memory. Some questions come to mind:
日记队列是否处于活动状态?这与队列相关联，如果队列被删除，我相信(不要引用我的话)那么日记从空开始...
Is the journal queue active? This is tied to a queue and if the queue is removed, I believe (don't quote me) that the journal then starts from empty...
队列上是否存在清除进程? 这些是交易队列吗?
Is there a Purge process on the queue? Are these transactional queues?
是否已应用所有当前Service Pack?我似乎想起了在遥远的过去对此服务包的修复.它可能取决于平台，但您未列出平台. 我相信有几种这种性质的服务包.
Are all current service packs applied? I seem to recall a fix on a service pack for this in the distant past. It is probably platform dependent but you do not list your platform. I believe there were several service packs of this nature.
您的磁盘空间如何?您是否正在遇到磁盘空间问题或磁盘碎片问题?文件(如果我还记得的话)存储在windows \ system32 \ msmq下.如果没有足够大小的块，它可能会变慢-通常在消息的存储/接收中，不确定读取.
What is your disk space like? Are you getting into a disk space issue or a fragmented disk issue? Files (if I remember) are stored in under windows\system32\msmq. If there are not enough blocks of the size needed, it might slow down - usually on store /receipt of the message, not sure about reads.
这些是公共队列还是私人队列?
Are these public or private queues?
性能监视器对分页池等有何看法?我相信每封邮件是70-80字节.
What does performance monitor say about paged pool etc? I believe it is 70-80 bytes per message.
: 专用队列是在本地计算机上注册的，而不是在目录服务中注册的，并且它们的属性不能由运行在远程计算机上的消息队列应用程序获得.消息队列通过将每个队列的描述存储在单独的文件中，从而在本地注册专用队列.本地计算机上的本地队列存储(LQS)文件夹."
from the MSDN document archives: "Private queues are registered on the local computer, not in the directory service, and their properties cannot be obtained by Message Queuing applications running on remote computers. Message Queuing registers private queues locally by storing a description of each queue in a separate file in the local queue storage (LQS) folder on the local computer."
因此，如果目录服务关闭，则公共队列不可用.另一方面，专用队列存储在本地文件系统中.
Thus, if the directory service is down, public queues are not available. Private queues on the other hand are stored in the local file system.
此机器应具有很多内存，以避免磁盘交换队列.坦率地说，由于性能问题，我从来没有尝试过在Windows XP机器上运行MSMQ-总是让它在带有很多内存的专用服务器机器上执行-但是后来，我们正在处理大量排队的项目，每个都很大. (成千上万个，每个都接近大小限制)
This machine should have a LOT of memory to avoid disk swap of the queue. I have never tried to run MSMQ on an Windows XP box frankly due to the issue of performance - have always had it executing on a dedicated server box with a LOT of memory - but then, we were working with a large set of queued items, of large size each. (many thousands, near the limit in size each)
文件系统和空文件:
默认情况下，空消息文件每六个小时删除一次.可以在注册表中通过在HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ MSMQ \ Parameters下设置MessageCleanupInterval REG_DWORD值来控制此时间间隔.应用程序不应不必要地保持打开游标的状态在很长一段时间内，游标可能指向已收到(并已从文件中删除)的消息.这些指针会阻止清除和删除空文件.
"Empty message files are deleted once every six hours, by default. This time interval can be controlled in the registry by setting the MessageCleanupInterval REG_DWORD value under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\Parameters. Applications should not keep cursors opened unnecessarily for a long time. Cursors might point to messages that were already received (and removed from files). These pointers prevent cleanup and deletion of empty files.
注意:正在运行的磁盘上应该有大量可用空间，以防止出现碎片问题.您可以尝试减少这6个小时的时间，以查看是否有帮助-从而不必跟踪空文件.
NOTE: You should have a significant amount of free space on the disk this is running on to prevent fragmentation issues. You COULD TRY reducing this 6 hour time frame to see if that helps - so it does not have to keep track of empty files.
请尝试确保计算机上没有任何其他活动可能使驱动器碎片化，例如浏览Internet.
Try to make sure there is not any other activity on the machine which might fragment the drive - such as browsing the Internet.
在公共队列中，有时会扩展此时间，以避免 Active Directory 交互的开销这可能很昂贵. 您需要在消息队列会话的两端添加此注册表值.否则，值最小的计算机将过早停止会话.向此注册表值添加较大值的常见原因是使会话保持活动状态，并避免创建消息队列会话的开销.在您的实例中，您可能需要缩短该值以帮助进行文件系统管理. (这是一个艰难的要求，坦率地说，必须考虑到这一点.)
On a public queue, sometimes this is extended to avoid the expense of Active Directory interaction which can be expensive. You need to add this registry value on both ends of a Message Queuing session. Otherwise, the computer with the smallest value will stop the session prematurely. A common reason to add this registry value with a large value is to keep sessions alive and avoid the overhead of creating Message Queuing sessions. In your instance, you might need to shorten the value to aid in file systems management. (This is a hard call to make, and frankly needs to be made with consideration).
至于修补程序: (可能更多，而并非我所看到的特定于您的问题)
As for hot fixes: (probably more out there, and not specific to your problem that I can see)
The MSMQ 1.0 hotfix described in http://support.microsoft.com/kb/304212. The reason for this hotfix is that Windows XP Message Queuing 3.0 independent clients are built as robust RPC clients. Without this hotfix, calls from Windows XP Message Queuing 3.0 independent clients to MQLocateNext fail.
http://support.microsoft.com/kb/823980
The RPC hotfix is described in http://support.microsoft.com/kb/823980. This hotfix is required to enable auditing on the client running Windows XP. This hotfix is also required to enable clients running Windows 2000 to complete Setup.
一个想法:性能监视器对您的内存状态问题有何看法?那里有很多磁盘交换吗?
One thought: what does the Performance monitor say about your memory status issues? Is there a lot of disk swapping going on there?
这篇关于MSMQ慢队列读取的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
