Ibm mq runmqsc和MQ Explorer之间队列深度不一致的原因

我们有一个监控工具，使用

runmqsc

和以下命令：

display qstatus(*) curdepth ipprocs

为报警目的检索队列深度（a）

脚本分析输出并将信息提供给数据库，因此我只是等待上面命令的原始输出，以确保脚本没有问题。这不太可能，因为所有其他队列都报告良好

所以问题是，它报告了一个特定队列的深度为139，并且这个值已经存在了很多小时。但是，该框上的MQ Explorer似乎认为队列中只有八条消息

因此，我的问题（希望）很简单：在什么情况下，

显示qstatus curdepth

在队列深度方面与MQ Explorer不一致？我是否应该从

runmqsc

收集一些其他指标来获得正确的深度？还是MQ Explorer不一定可靠？（b）

---

（a） 产生警报的目的，而不是你应该警惕的目的

---

（b） 是的，我知道有三个问题。我更愿意将其视为同一问题的三个方面。

MQExplorer的默认刷新间隔为15秒，这意味着MQExplorer内容每15秒使用队列管理器统计信息刷新一次。另一方面，runmqsc命令在执行命令时显示静态。因此，“不同意”可能是因为MQExplorer视图未刷新

您执行了错误的命令。QStatus正在报告高值，并将继续报告，直到针对队列执行ResetQ命令，然后它将再次报告高值

您应该使用以下MQSC命令：

display qlocal(*) curdepth ipprocs

---

runmqsc和mqexplorer（通过PCF）都显示队列管理器给它们的相同值。如果两个命令在同时发出，它们将给出sme答案。当然，CURDEPTH是一种可以快速变化的东西，因此请确保它不仅仅是使用一种工具和另一种工具发出命令之间的深度变化。

好的方面，我应该提到队列在大约8小时前的凌晨跳到了139。我将澄清这个问题。

display qstatus

的doco将

curdepth

描述为“队列的当前深度，即队列上的消息数”（我的粗体）。是什么让你认为这是一个高水位线？作为测试，我将7000多个事务放入一个队列中，

qstatus

和

qlocal

都有

curdepth

。当我清空队列时，两个都报告为零。罗杰，我想你把Qstats和Qstats混在一起了好几个星期了，深度都是8，这是因为我们只做了相关的get，这意味着我们等待超时的消息（后来仍然收到）留在了队列中。然后，在我发布问题的八小时前，由于同样的原因，它跳到了140多个。由于消息传入并被检索，队列深度上下波动，而这140多条消息从未移动过（想想

89898910108140141140…

）。所以我很确定这不是Explorer和runmqsc之间的时间问题。话虽如此，我刚刚收到来自支持BOD的通知，当他们关闭Explorer并重新启动它几次时，它最终恢复良好并开始报告较高的数字。因此这可能是“最好的”答案是，这会增加延迟的可能性。为什么它需要几天的时间，为什么它必须重新启动一次以上，我不知道，但它现在已经修复。从现在起，我只信任runmqsc:-）