我们遇到一个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条件。