【发布时间】：2011-10-12 13:42:21
【问题描述】：
我们遇到过linux环境下空队列占用磁盘空间的场景。
我们的队列管理器意外结束，因为文件系统已满，我们需要清空 q 文件以恢复队列管理器。
但实际上我们在队列中根本没有任何消息。这显示了一个特定的队列。
为什么磁盘空间被保留在这里？根本原因是什么？
【问题讨论】：
标签： ibm-mq
【发布时间】：2011-10-12 13:42:21
【问题描述】：
WMQ 不会实时收缩队列文件。例如，您在一个队列中有 100 条消息，并且您使用了第一条消息。 WMQ 不会收缩文件并将所有消息向上移动一个位置。如果它尝试对每条消息都这样做，您将永远无法获得您当前在产品中看到的吞吐量。
确实发生的是 WMQ 将在处理生命周期的某些点收缩队列文件。在队列变空和其下的文件缩小之间存在一定的延迟，但这种延迟通常非常小，不会引起注意。
您所描述的事件理论上可能在某些非常特定的条件下发生，但这将是极其罕见的。事实上，在我使用 WMQ 的 15 年中，我只见过几个实例，其中缩小队列文件的延迟甚至很明显。我猜这里实际发生的是您的假设或观察之一是错误的。例如：
队列实际上是空的吗？
- 队列绝对是空的在你炸掉文件之后。你怎么知道它是空的之前你吹走了文件？
- 如果任何队列上有非持久消息，QMgr 重新启动后队列将为空。这是另一种情况，在 QMgr 重新启动后队列可能看起来为空，但在失败时并非如此。
- 如果从同步点下的队列中检索到消息，队列深度会递减，但消息在队列文件中仍处于活动状态。如果一个队列在单个事务中被清空，它会保留它的完整深度，直到 COMMIT 发生。这可以使队列看起来像不是空的。
实际上是队列文件填满了文件系统吗？
- 日志范围可以填满文件系统，即使是循环日志。例如，使用较大的辅助扩展区值，日志文件可以显着扩展，然后很快消失。
- FDC 文件可能会填满文件系统，具体取决于分配方式。
它甚至是 MQ 吗？
- 如果 QMgr 与其他用户或应用共享文件系统空间，临时文件可能会填满空间。
我们经常看到的问题之一是应用程序会尝试将超过 5,000 条消息放入队列并收到 QFULL 错误。大多数人做的第一件事就是设置 MAXDEPTH(999999999) 以确保这种情况不再发生。这样做的问题是 QFULL 是一个软错误，应用程序可以从中恢复，但填充文件系统是一个硬错误，可能会导致整个 QMgr 崩溃。设置 MAXDEPTH(999999999) 会将可管理的软错误换成致命错误。 MQ 管理员有责任确保队列上的 MAXDEPTH 和 MAXMSGL 设置为不会填满底层文件系统。在大多数商店中，对所有文件系统都进行了额外的监控，以便在它们填满之前发出警报。
总而言之，WMQ 在大多数情况下都可以很好地缩小队列文件。特别是，当队列清空时，这是一个自然的同步点，在该点文件可以收缩，这通常发生在队列清空的几秒钟内。您遇到了罕见的竞争条件，其中文件没有足够快地收缩，或者这里发生了其他事情，在您的初始分析中并不明显。在任何情况下，管理 MAXDEPTH 和 MAXMSGL 使得没有队列可以填满文件系统并编写代码来处理 QFULL 条件。
【讨论】：