ibm-mq - websphere mq 中的队列存储文件系统已满

Question

我们在linux环境中遇到过磁盘空间被空队列占用的场景。

随着文件系统变满，我们的队列管理器意外结束，我们需要清空 q 文件以恢复队列管理器。

但实际上我们在队列中根本没有任何消息。这显示了一个特定的队列。

为什么磁盘空间保存在这里？根本原因是什么？

Answer 1

WMQ 不会实时收缩队列文件。例如，您在一个队列中有 100 条消息，并且您使用了第一条消息。然后 WMQ 不会收缩文件并将所有消息向上移动一个位置。如果它试图对每条消息都这样做，您将永远无法获得当前在产品中看到的吞吐量。

确实发生的是 WMQ 将在处理生命周期的某些点收缩队列文件。队列变空和它下面的文件缩小它之间存在一些延迟，但这种延迟通常很小，以至于无法察觉。

您所描述的事件理论上可能发生在某些非常特定的条件下，但这种情况极为罕见。事实上，在我使用 WMQ 的 15 年里，我只见过几个实例，其中缩小队列文件的延迟甚至很明显。我猜想这里实际发生的事情是您的假设或观察之一是错误的。例如:

队列实际上是空的吗？

在你吹掉文件后，队列肯定是空的。在你吹掉文件之前你怎么知道它是空的？

如果任何队列上存在非持久消息，则在 QMgr 重新启动后队列将为空。这是另一种情况，在 QMgr 重新启动后队列可能看起来是空的，但在失败时却不是。

如果从同步点下的队列中检索消息，队列深度会减少，但该消息在队列文件中仍处于事件状态。如果队列在单个事务中被清空，它会保留它的完整深度，直到发生 COMMIT。这可以使它看起来像队列不是空的。

它实际上是填满文件系统的队列文件吗？

日志范围可以填满文件系统，即使是循环日志。例如，如果二级盘区的值较大，日志文件可能会显着扩大，然后很快消失。

FDC 文件可以填满文件系统，具体取决于分配的方式。

甚至是MQ吗？

如果 QMgr 与其他用户或应用程序共享文件系统空间，临时文件可能会填满空间。

我们经常看到的问题之一是应用程序将尝试将超过 5,000 条消息放入队列并收到 QFULL 错误。大多数人做的第一件事就是设置 MAXDEPTH(999999999) 以确保这种情况不再发生。问题在于 QFULL 是一个软错误，应用程序可以从中恢复，但填充文件系统是一个硬错误，它会导致整个 QMgr 崩溃。设置 MAXDEPTH(999999999) 会将可管理的软错误换成 fatal error 。 MQ 管理员有责任确保队列上的 MAXDEPTH 和 MAXMSGL 设置为不填充底层文件系统。在大多数商店中，对所有文件系统都进行了额外的监控，以便在警报填满之前发出警报。

所以综上所述，WMQ在大多数情况下在缩小队列文件方面做得非常好。特别是，当队列清空时，这是一个自然的同步点，文件可以在此时收缩，这通常发生在队列清空后的几秒钟内。您要么遇到了罕见的竞争条件，其中文件收缩得不够快，要么这里发生了其他一些在您的初始分析中并不明显的事情。在任何情况下，管理 MAXDEPTH 和 MAXMSGL 以便没有队列可以填满文件系统并编写代码来处理 QFULL 条件。