基于这个线程，似乎MSMQ进程占用了大量的内存是“正常的”，直到内存压力。
在工作集内存上，似乎大多数监视工具都基于内存使用情况。 这包括我们目前使用的（New Relic），它使用这个PowerShell查询：
Get-WmiObject -Query "SELECT CommitLimit,CommittedBytes,AvailableBytes FROM Win32_PerfRawData_PerfOS_Memory" 任务pipe理器似乎也使用工作集内存作为其默认的内存图。
我们通常看到内存使用率（基于工作集）秒杀到90％以上，根据上面的线程链接，并不是不正常的。
在使用MSMQ的计算机上查看高内存使用情况是否相当标准？ 标准做法是不要监视这些机器的内存使用情况？
所有Windows Vista +版本中的内存使用情况设置为尽可能多地保留内存。 这是最有效的方式，因为它阻止从磁盘读取，从RAM中清空不需要的页面比从磁盘填充这些页面花费的时间要less得多。 你看到的同样的问题适用于MSSQL服务器，Exchange，其他任何有大量RAM使用，因为他们将尽可能加载到RAM尽可能在任何点。
如果您没有看到实际的问题（分页输出操作（磁盘抖动），其他应用程序中的内存不足错误或其他应用程序的性能问题），则可以安全地忽略高内存使用情况。 空RAM是不需要的RAM。 相反，如果您希望机器上的内存使用率很高，而且您看到的是零用量，则可能存在问题。
至于监视内存的使用情况，如果你只监视使用的总内存，我将停止高层次的警报。 保持低RAM利用率的警报，就像在一个服务器上的低CPU利用率一样，这个服务器的应用程序在空闲时保持CPU在20％（或其他） 。 如果您正在监视什么应用程序正在使用多less内存，并且服务器正在托pipe多个应用程序，则可能需要testing其他应用程序，而不运行MSMQ，以便您可以精确地表示它们在给定的情况下将使用多lessRAM机会，并调整分配和监测来考虑这些需求。
在我们的组织中，我们已经停止监视所有服务器上的高内存消耗， 它什么都不做，只是触发需要被禁止的警报，并混淆正常的警报。
这篇文章有一些关于如何改变内存pipe理的高层次的信息，从那时起，内存pipe理器并没有发生巨大的变化，AFAIK。
MSMQ内存使用量与消息量直接相关。 如果内存使用率很高，那么MSMQ正在pipe理大量的消息。 您最好决定什么是日常使用的预期消息量，并在数字高于该水平时提醒。
如果大量的消息被认为是正常的，那么博客上的第4项也是重要的。