我们遇到了
Linux环境中空队列占用磁盘空间的情况.

我们的队列管理器意外结束,因为文件系统已满,我们需要清空q文件以恢复队列管理器.

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

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

最佳答案 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条件.