隊列存儲文件系統完全在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）會爲致命錯誤交易可管理的軟錯誤。 MQ管理員有責任確保隊列上的MAXDEPTH和MAXMSGL設置爲底層文件系統不填充。在大多數商店中，對所有文件系統都進行了額外的監控，以在警報填滿之前提醒警報。

所以總結一下，在大多數情況下，WMQ在縮小隊列文件方面做得非常好。特別是，當一個隊列清空時，這是一個自然的同步點，文件可以被縮小，這通常發生在隊列清空的幾秒鐘內。你要麼遇到一種罕見的競爭條件，即文件沒有足夠快地收縮，或者在這裏有其他事情在你的初始分析中不明顯。在任何情況下，都應該管理MAXDEPTH和MAXMSGL，使得沒有隊列可以填充文件系統並編寫代碼來處理QFULL條件。