WebSphere MQ 共享隊列與應用程序 （1）

引言

有很多討論 IBM® WebSphere® MQ 共享隊列的資料，特別是討論其提供消息持續可用性方面的資料更是數不勝數。但在規劃和實現期間出現了很多關于如何最好地使用共享隊列及其對應用程序的影響方面的問題。其中一些問題得到了廣泛的關注（如確保數據序列化的應用程序代碼等），而其他問題卻沒有得到足夠的重視。本文所給出的建議均以生產環境中的實現為基礎，通常包含可應用于所有 WebSphere MQ 應用程序的最佳實踐。除非應用程序可靠且具備高可用性，否則在保證基礎設施可靠且具備較高可用性方面所作的努力將效果甚微，因此，應用程序最佳實踐對共享隊列實現的成功也至關重要。

一些共享隊列的主題并未在本文中涉及。WebSphere MQ V6 包含了一個新功能，允許共享隊列中存在大于 63K 的消息，但由于在撰寫本文時并未在任何生產環境中實現 WebSphere MQ V6，因此并不討論此類消息對應用程序和資源利用方面的影響。此外，也不會討論共享通道和組內隊列。

示例應用程序

本文中所使用的示例應用程序名為 PTR。它所預期處理的消息量是每天 1,000,000 條消息（后文將討論峰值速率），消息平均大小為 3.5K（含消息描述符——MQMD）。這些消息分布在兩個隊列中，兩個隊列中的消息量平均分配。這些消息將由一個名為 PTRC 的 CICS 事務進行處理。

問題 1：Coupling Facility 列表結構和隊列大小

與私有隊列不同（私有隊列的大小受頁集大?。ǜ鶕?WebSphere MQ 不同，最大為 4G 或 64G）的限制），共享隊列的大小受到應用程序列表結構大小的限制。此結構是 Coupling Facility (CF) 中的已分配存儲區域。CF 是一個公共資源，由系統本身使用：DB2、CICS、IMS 和其他 WebSphere MQ 結構。該結構的大小是由 z/OS 系統管理員通過 IXCMIAPU 設置的。每個 WebSphere MQ 隊列共享組 (QSG) 都至少需要使用兩個結構，一個用于進行管理的結構，以及一個或多個應用程序結構。

在實際中，大部分隊列共享組都定義為一個管理結構和至少兩個應用程序結構，一個用于持久性信息，一個用于非持久性消息。WebSphere MQ 管理員需要知道持久性消息是否會進入共享隊列?？梢匀菁{持久性和非持久性消息的混合的隊列必須在持久性列表結構中定義。

CF 所施加的大小限制使得一些客戶詢問這樣的問題：它們的大容量應用程序是否適合使用共享隊列。在某些情況下，CF 容量并不妨礙共享隊列的使用，例如，在批處理作業中就是這樣（此類作業中數百萬消息長時間處于一個隊列中）。但在大多數情況下，這個問題被估計過高了，而實際如何使用隊列（例如，消息通常在隊列中保持多長時間）對于確定使用共享隊列是否恰當更為重要。

與 WebSphere MQ 一起提供的示例應用程序設置的初始大小為 266 MB，最大大小為 512 MB。這一部分將向您演示如何計算按照定義可以將多少 PTR 消息放入該結構中。

關于應用程序組的討論應該可以幫助確定在峰值期間預期的最大深度、消息的大小以及隊列上的預期持續時間。在知道消息處理速率和實際用戶使用系統之前，進行這些評估可能有些困難。但和進行容量規劃工作一樣，您需要一個基準。

評估應用程序結構的需求情況

假定應用程序開發人員要求隊列上應該有足夠容納每天預期消息量的 20% 的空間，以便能處理峰值期間大量消息涌入系統或較慢的事務處理無法跟上請求提交的速度時的情況。此行為屬于例外，僅會在網絡或應用程序停工期間出現。要求僅容納 PTR 消息的 CF 結構大小應為：

• 1M 消息的 20% = 200,000
• 平均消息大小 = 3.5K = 3584
• 消息數量 * 大小 = 200,000 * 3584 = 716,800,000
• 加上 30% 的系統開銷 = 931,840,000（請參閱下面的注釋）
• 所需的 1K 大小頁面的數量 = 910,000 = 889 MB = 近 1GB

注:30% 的系統開銷允許量是基于 Coupling Facility Control Code (CFCC) 第 12 級確定的。如果您的 CFCC 級別不同，此值可能會有變化。有關更多信息，請參閱 WebSphere MQ SupportPac MP16: Capacity Planning and Tuning for WebSphere MQ for z/OS。

889 MB 的要求可能并不現實；事實上，這比 WebSphere MQ V5.3 所定義的缺省應用程序結構大小還要大。當與 z/OS 系統程序員進行討論時，提出這個值可能會讓他們覺得好笑。如果此值過高，那么預期日消息流量的 5% 如何呢？如果 1,000,000 MPD 為一個非常準確的速率，那么這個值就為一個多小時內的消息量。計算過程如下：

• 1M 消息的 5% = 50,000
• 平均消息大小 = 3.5K = 3584
• 消息數量 * 大小 = 50,000 * 3584 = 179,200,000
• 加上 30% 的系統開銷 = 232,960,000
• 所需的 1K 大小頁面的數量 = 227,500 = 223 MB

此值也可能不太現實，因為其大小幾乎占據了整個初始結構大小。如果 PTR 隊列已填滿，則在該結構中定義了隊列的其他應用程序可能會受到影響。

1% 的最低容量要求可能是唯一可行的選項：

• 1M 消息的 1% = 10,000
• 平均消息大小 = 3.5K = 3584
• 消息數量 * 大小 = 10,000 * 3584 = 35,840,000
• 加上 30% 的系統開銷 = 46,592,000
• 所需的 1K 大小頁面的數量 = 45,500 = 45 MB

1 2 3 4 5 下一頁>>

原文轉自：http://www.anti-gravitydesign.com