|
| |
| Sun Java System Message Queue 3.5 SP1 管理指南 | |
第 9 章
分析與調整訊息服務本章涵蓋一些如何分析與調整 Message Queue 服務的主題，以最佳化您訊息傳送應用程式的效能。它包括以下主題：
關於效能效能調整程序
訊息傳送應用程式的效能取決於應用程式和 Message Queue 服務間的互動。因此，最佳化效能需要應用程式開發人員和管理員共同的努力。
最佳化效能的程序以應用程式設計為起點，接著在部署應用程式後，調整訊息服務繼續。效能調整程序包括以下階段：
以上略述的程序通常是反覆的。應用程式部署期間，Message Queue 管理員會評估應用程式一般效能需求的訊息伺服器合適性。如果效能評定測試符合這些需求，管理員可以根據本章說明調整系統。但是，如果效能評定測試不符合效能需求，則可能需要重新設計應用程式或修改架構部署。
效能類型
一般而言，效能為訊息服務從產生者發送訊息到使用者之速度和效率的測量。但是，依您的需要，您可能需要注意幾個不同方面的效能。
連接負載 可支援訊息產生者、訊息使用者或運作之連接系統的數目。
穩定性 訊息服務的整體可用性，或如何逐漸降低可用性以防大量負載或失敗。
通常這些不同方面的效能是相互關聯的。如果訊息流量高，則表示訊息較不可能儲存於訊息伺服器中，因此，延時時間短 (單一訊息可迅速發送)。但是，延時可取決於很多因素：通訊連結的速度、訊息伺服器處理速度和用戶端處理速度等。
無論如何，會有數個不同方面的效能。對您最重要的方面通常取決於特定應用程式的需求。
效能評定
效能評定為建立用於您訊息傳送應用程式與測量訊息流量之測試套件的程序，或用於此測試套件的其他方面效能。
例如，您可能會以數個生產型用戶端，使用數個連接、階段作業和訊息產生者來建立測試套件，並以某特定速率，將標準大小的永久性或非永久性訊息傳送到數個佇列或主題 (所有皆取決於您訊息傳送應用程式設計)。同樣地，測試套件包括數個使用數個連接和階段作業的使用用戶端以及在測試套件目標中，以特定確認模式使用訊息的訊息使用者 (特定類型)。
使用標準的測試套件，您可以測量訊息產生和使用間所需的時間或平均訊息流量速率，並且可以監視系統以觀察連接執行緒用法、訊息儲存資料、訊息流量資料和其他相關度量。接著，您可以在對效能產生不良影響前，急速增加訊息產生的速率、訊息產生者的數目或其他變數。您可以達到的最大流量為您訊息服務配置的效能評定。
使用此效能評定，您可以修改部分您測試套件的特徵。藉由小心控制所有可能影響效能的因素 (請參閱「影響效能的應用程式設計因素」)，您可以注意到變更部分因素會如何影響效能評定。例如，您可以將連接數目或訊息大小增加五倍或十倍，即可發現效能受到影響。
相反地，您可以將基於應用程式的因素維持一致，並以某種控制方法變更您的代理程式配置 (例如，變更連接特性、執行緒儲存區特性、JVM 記憶體限制、限制行為、內建與外掛持續性等)，接著您可以注意到這些變更如何影響效能。
您應用程式的效能評定會提供資訊，這些資訊在您要藉由調整訊息服務，以增加已部署應用程式的效能時會有所幫助。效能評定可以更加準確地預測一個變更或一組變更的效果。
一般來說，應在受控制的測試環境中，於一段足以穩定您訊息服務的長時間內執行效能評定。(啟動時，Just-In-Time 編譯會將 Java 程式碼轉為機器程式碼，這會對效能造成不良影響 。)
基本使用式樣
一旦部署並執行訊息傳送應用程式，建立基本使用式樣是很重要的。您必須知道尖峰需求何時出現並可以將需求數目化。例如，需求通常會因一般使用者的數目、活動級別、天數或前述所有因素而有變化。
若要建立基本使用式樣，您必須長時間監視您的訊息伺服器，查看像是連接數目、儲存於代理程式中 (或特定目標中) 的訊息數目、流入或和流出代理程式 (或特定目標) 的訊息流量、作用中使用者數目等等的資料。您還可以使用度量資料中提供的平均與尖峰值。
檢查這些出乎設計意料之外的基本度量是非常重要的。經由此動作，您會檢查用戶端程式碼是否正常運作：例如，連接未處於開啟狀態或使用的訊息未處於未確認狀態。這些程式碼錯誤會使用訊息伺服器資源，且可能會明顯影響效能。
基本使用式樣可幫助您判斷如何將系統調整到最佳化效能。舉例來說，如果某個目標的使用度較其他目標高，那麼您可能要將此目標的訊息記憶體限制設定的比其他目標的限制高，或者要相應地調整限制行為。如果所需的連接數目明顯大於最大執行緒儲存區容量允許的大小，那麼您可能要增加執行緒儲存區大小，或調整共用執行緒模型。如果尖峰訊息流量遠遠大於平均流量，那麼在記憶體不足時，可能會影響您使用的限制行為。
一般而言，您對使用式樣的瞭解越多，您調整系統用於未來需求的式樣與計劃的能力越好。
影響效能的因素訊息延時和訊息流量為兩個主要的效能指標，它們的值通常取決於一般訊息完成訊息發送程序中各個步驟所花費的時間。以下顯示的步驟用於永久性、可靠且已發送之訊息的情況下。下圖描述這些步驟。
圖 9-1 透過 Message Queue 服務的訊息發送
由於這些步驟是連續性的，所以在從生產型用戶端發送訊息至使用用戶端時，這其中任何一個步驟都是可能遇到的瓶頸。大部分的步驟取決於訊息傳送系統的實體特徵：網路頻寬、電腦處理速度、訊息伺服器架構等。但是，還有些步驟是取決於訊息傳送應用程式的特徵和要求的可靠性級別。
以下小節說明應用程式設計因素與訊息傳送系統因素對效能的影響。當在訊息傳送中應用程式設計和訊息傳送系統因素相互操作時，將單獨的考慮每個種類。
影響效能的應用程式設計因素
應用程式設計決策會對整體訊息傳送效能產生顯著的效果。
影響效能最重要的因素為影響訊息發送可靠性的因素。這些因素如下：
其他影響效能的應用程式設計因素如下：
以下各節描述影響訊息傳送效能的各個因素。一般來說，要在效能與可靠性間取得平衡：即提昇可靠性的因素往往會降低效能。
以下表格顯示各種應用程式設計因素通常如何影響訊息傳送效能。表格顯示兩個方案 - 高可靠性和低效能方案、高效能和低可靠性方案 - 且顯示特定應用程式設計因素的選擇。在這兩個方案中，有許多影響可靠性和效能的選擇和平衡。
備註
以下各圖為使用基於檔案的持續性，在雙 CPU、1002 Mhz、Solaris 8 系統上產生的效能資料。效能測試首先會預熱 Message Queue 代理程式，以便 Just-In-Time 編譯器最佳化系統和預備的永久性資料庫。
預熱代理程式後，會建立一個產生者和使用者，並以 30 秒的時間產生訊息。會記錄使用者接收所有產生訊息的所需時間，且計算流量速率 (每秒幾個訊息)。會在應用程式設計因素的不同組合，重複使用此方案，如表 9-1 所示。
發送模式 (永久性/非永久性訊息)
如「可靠的訊息傳送」中所述，永久性訊息可確保訊息伺服器故障情況下的訊息發送。代理程式會在所有預定使用者確認他們已使用訊息前，將訊息儲存在永久性儲存體中。
永久性訊息的代理程式處理速度會比非永久性的訊息處理速度慢，原因如下：
永久性和非永久性模式間效能的差異性非常明顯。圖 9-2 比較兩個可靠發送情況下，永久性和非永就性訊息的流量：發送 10K 大小的訊息到佇列和包含長期訂閱的主題。這兩種情況皆會使用 AUTO_ACKNOWLEDGE 確認模式 。
圖 9-2 發送模式的效能影響
異動使用
異動是所有異動階段作業中產生訊息和使用訊息的保證，兩種訊息的處理方法如下：處理作為一個單位、不處理 (回轉) 作為一個單位。
Message Queue 支援本地和分散式異動 (請個別參閱「本地異動」 和「分散式異動」，以獲得更多資訊)。
異動階段作業中產生或回應訊息的速度會比在非異動階段作業中的速度慢，原因如下：
確認模式
JMS 訊息發送的確保可靠性機制，是用戶端用來確認 Message Queue 訊息伺服器所發送到其自身的訊息使用 (請參閱「可靠發送：確認與異動」)。
如果在用戶端未確認訊息時關閉階段作業，或在處理確認前訊息伺服器發生故障，則代理程式會重新發送訊息，並設定 JMSRedelivered 旗標。
對非異動階段作業而言，用戶端可以選擇三種確認模式中的其中一種模式，每一個模式皆擁有各自的效能特徵：
(使用 CLIENT_ACKNOWLEDGE 模式與使用異動相似，但在處理期間提供者發生故障時，前者不確保會一起處理所有確認。)
效能受到確認模式影響的原因如下：
長期與非長期訂閱
如「出版/訂閱 (主題目標)」中所述，至主題目標的用戶分為兩個種類，使用長期或非長期訂閱：
長期訂閱可提高可靠性，但會降低流量，原因如下：
圖 9-3 比較包含長期與非長期訂閱兩種情況的主題目標流量：永久性與非永久性的 10K 大小訊息。這兩種情況皆會使用 AUTO_ACKNOWLEDGE 確認模式
您可以從圖 9-3 發現只有在永久性訊息的情況下，使用長期訂閱才會對效能產生明顯影響；如同上述說明，在此情況下發生影響是因為只會持續儲存用於長期訂閱的永久性訊息。
圖 9-3 訂閱類型的效能影響
選擇器的使用 (訊息過濾)
應用程式開發人員通常會將訊息組指向特定使用者。他們會藉由將每個訊息組指向唯一目標，或使用單一目標並為使用者註冊一個或多個選擇器，以達成此目的。
選擇器為一字串，請求僅將包含符合此字串之特性值 (請參閱「JMS 訊息結構」) 的訊息發送到特定使用者。例如，選擇器 NumberOfOrders >1 僅會發送包含 NumberOfOrders 特性值 2 或更高值的訊息。
以選擇器註冊使用者會降低效能 (與使用多個目標相比較的話)，因為需要額外處理每個訊息。使用選擇器時必須剖析選擇器，如此一來，選擇器可與之後的訊息相符合。此外，在路由每個訊息時，必須擷取每個訊息的訊息特性並與選擇器進行比較。但是，使用選擇器可在訊息傳送應用程式中提供更多彈性。
訊息容量
訊息容量會影響效能，因為必須將更多資料從生產型用戶端傳送到代理程式，再從代理程式傳送到使用用戶端，且必須儲存較大的永久性訊息。
但是，藉由將較小訊息批次到單一訊息，可以最小化個別訊息的路由和處理，以提供整體效能改善比率。在此情況下，會遺失個別訊息狀態的相關資訊。
圖 9-4 比較兩種情況下，1K、10K 和 100K 大小訊息每秒的流量 (以千位元組為單位)：永久性與非永久性的訊息。在所有情況下，皆會將訊息傳送到佇列目標，並使用 AUTO_ACKNOWLEDGE 確認模式。
圖 9-4 顯示在兩種情況下，發送較大訊息的耗用時間會比發送較小訊息的耗用時間短。您也可以發現在 1K 與 10K 大小訊息中，非永久性訊息的效能改善比率比永久性訊息的效能改善比率高出將近 50%，但在 100K 大小訊息中並沒有這種情形，這可能是因為在此情況下，網路頻寬成為訊息流量的瓶頸。
圖 9-4 訊息容量的效能影響
訊息內文類型
JMS 支援五種訊息內文類型，以下大致上依其複雜性順序顯示：
一般而言，依應用程式需求規定訊息類型時，更複雜的類型 (MapMessage 和 ObjectMessage) 會增加效能耗用 - 串列化和解串列化資料的效能。效能耗用取決於資料簡單或複雜的程度。
影響效能的訊息服務因素
訊息傳送應用程式的效能不只受到應用程式設計的影響，還受到執行訊息路由和發送的訊息服務影響。
以下各節介紹可影響效能的這種訊息服務因素。瞭解這些因素的影響是調整訊息服務大小、及診斷和解決已部署應用程式中可能會出現之效能瓶頸的關鍵。
影響 Message Queue 服務中效能的最重要因素如下所述：
以下各節描述影響訊息傳送效能的各個因素。
硬體
對 Message Queue 訊息伺服器和用戶端應用程式而言，CPU 處理速度和可用記憶體，是決定訊息服務效能的主要因素。增加處理能力可以減少許多軟體限制，而增加記憶體可以同時增加處理速度和能力。然而，升級硬體以克服這些瓶頸通常需要一筆花費。
作業系統
因為不同作業系統的效率，效能會有所變化，即使是在同樣的硬體平台亦有差別。例如，作業系統部署的執行緒模型，對訊息伺服器可支援的運作連接數目會有極大影響。一般而言，在所有硬體皆同等的情況下，Solaris 系統通常會比 Linux 系統快，而 Linux 系統又比 Windows 系統快。
Java 虛擬機器 (JVM)
訊息伺服器為在主要 JVM 中執行且支援的 Java 程序。因此，JVM 處理是決定訊息伺服器路由和發送訊息之速度和效率的重要因素。
要特別注意的是，JVM 的記憶體資源管理是非常重要的。必須在 JVM 配置足夠的記憶體，以適應增加的記憶體負載。除此之外，JVM 會定期回收未使用的記憶體，且記憶體回收會延遲訊息處理。JVM 記憶體堆疊的容量越多，記憶體回收過程中可能發生的延遲時間越長。
連接
用戶端和代理程式間的連接數目和速度，會影響訊息伺服器處理訊息的數目和發送訊息的速度。
訊息伺服器連接限制
所有訊息伺服器的存取皆是透過連接。運作中連接數目的任何限制，皆會影響目前使用訊息伺服器之生產或使用用戶端的數目。
至訊息伺服器的連接數目通常會受到可用執行緒數目的限制。Message Queue 會使用執行緒儲存區管理程式，以便配置支援專用的執行緒模型或共用的執行緒模型 (請參閱「執行緒儲存區管理程式」)。專用的執行緒模型執行速度非常快，因為每個連接均有專用執行緒；但是，連接數目受到可用執行緒數目的限制 (每個連接使用一個輸入執行緒和一個輸出執行緒)。共用執行緒模型在連接數目上沒有限制；但是，在連接數目超過共用執行緒時，會產生明顯的耗用時間和流量延遲，特別是在連接忙碌時。
傳輸協定
Message Queue 軟體可讓用戶端使用各種低層傳輸協定，與訊息伺服器進行通訊。Message Queue 支援「連接服務支援」中敘述的連接服務 (和對應的協定)。協定的選擇是根據應用程式需求而異 (加密、透過防火牆的存取權)，而選擇會影響整體效能。
圖 9-5 傳輸協定速度
圖 9-5 反映各種協定技術的效能特徵：
訊息伺服器架構
可以將Message Queue 訊息伺服器實施作為單一代理程式或多重互連代理程式實例 - 代理程式叢集。
隨著連接至代理程式的用戶端數目的增加，以及要發送的訊息數目的增加，代理程式將最終超過資源限制 (如檔案描述元、執行緒和記憶體限制)。提供增加載入的一個方法為將多個代理程式實例新增至 Message Queue 訊息伺服器，從而在多重代理程式間分布用戶端連接與訊息路由和發送。
一般而言，此調整會使運作達到最佳狀態，如果用戶端 (尤其是訊息生產型用戶端) 在叢集上平均分散的話。由於耗用時間受到叢集中代理程式間訊息發送的影響，所以包含連接數目限制或訊息發送速率限制的叢集，所表現效能可能會比單一代理程式低。
您還可以使用代理程式叢集來最佳化網路頻寬。例如，您可以在叢集中一組遠端代理程式間使用較慢、距離較長的網路連結，而使用較高速度的連結將用戶端連接至其各自的代理程式實例。
如需更多叢集的相關資訊，請參閱「多重代理程式叢集 (企業版)」和「使用叢集 (企業版)」。
代理程式限制和行為
訊息伺服器可能處理的訊息流量是訊息伺服器所支援之訊息傳送應用程式使用式樣的函數。然而，訊息伺服器在資源上受到限制：記憶體、CPU 週期等。因此，訊息伺服器可能會對點過度負載，造成沒有確認或不穩定的情況。
Message Queue 訊息伺服器有管理記憶體資源和預防代理程式耗盡記憶體的內建機制。這些機制的可配置限制包括代理程式可保留的訊息數目和訊息容量、其個別目標，以及達到目標限制時可採取的行為 (請參閱「管理記憶體資源和訊息流量」。
藉由謹慎監視與調整，這些可配置機制可用來平衡流入和流出訊息，如此一來，將不會發生系統過度負載情況。這些機制會耗用時間並限制訊息流量，但他們會維護作業完整性。
資料倉庫效能
Message Queue 支援內建和外掛持續性 (請參閱「持續性管理程式」)。內建持續性是基於檔案的資料倉庫。外掛持續性使用 Java 資料庫連接 (JDBC™) 介面，並需要 JDBC 相容的資料倉庫。
內建持續性速度明顯比外掛持續性快；但是，JDBC 相容的資料庫系統可能會提供應用程式需要的容錯、安全與管理功能。
在使用內建持續性的情況下，您可以指定持續性作業同步化包含資料倉庫的內部記憶體狀態，以最大化可靠性。這可以消除因系統當機而產生的資料遺失，但會影響效能。
用戶端運行時間配置
Message Queue 用戶端運行時間會提供用戶端應用程式到 Message Queue 訊息服務的介面。它支援用戶端將訊息傳送至目標和從此類目標接收訊息所需的所有作業。用戶端執行時間是可配置的 (藉由設定連線工廠屬性值)，它可讓您設定可改善效能與訊息流量的特性與行為。
例如，Message Queue 用戶端執行時間支援以下可配置行為：
- 連接流量計數 (imqConnectionFlowCount)，可幫助您避免 JMS 訊息和 Message Queue 控制訊息同時通過同一連接時，產生擁塞情形。
- 連接流量限制 (imqConnectionFlowLimit)，可幫助您藉由限制可透過連接發送至用戶端運行時間的待使用訊息數目，來避免用戶端資源限制。
- 使用者流量限制 (imqConsumerFlowLimit)，可在多使用者佇列發送情況中，幫助改善使用者之間的負載平衡 (沒有使用者會收到過多的訊息數)，並且有助於平衡所有連接使用者的流量。此特性限制每個使用者在連接中可發送到用戶端運行時間的待使用訊息數目。也可將此特性配置為佇列目標特性 (consumerFlowLimit)。
如需更多用於配置之行為和屬性的相關資訊，請參閱「用戶端運行時間訊息流量調整」。
監視訊息伺服器可配置 Message Queue 伺服器，以提供用來監視其效能的度量資訊。本節描述您可用來監視訊息伺服器的各種工具，以及使用這些工具來取得的度量資料。
如需如何使用度量資料以排解效能問題或分析與調整伺服器效能的資訊，請參閱「排解效能問題」。
監視工具
您可以使用以下工具取得度量資訊：
以下各節描述如何使用這些工具來取得度量資訊。如需不同工具的比較，請參閱「選擇正確的監視工具」。
Message Queue 指令行公用程式 (imqcmd)
指令行公用程式 (imqcmd) 為 Message Queue 的基本指令行管理工具。它可讓您管理代理程式及其連接服務，亦可管理應用程式特定的資源，例如實體目標、長期訂閱和異動。imqcmd 指令在第 6 章「代理程式和應用程式管理」進行說明
imqcmd 指令的其中一個功能是可取得用於作為整體之代理程式、個別連接服務和個別目標的度量資訊。若要取得度量資料，通常可使用 imqcmd 子指令 metrics。度量資料會依您指定的間隔時間或次數寫入主控台畫面。
您也可以使用 query 子指令 (請參閱「imqcmd query」) 取得更多限制的度量資料子集。
imqcmd metrics
imqcmd metrics的語法和選項個別顯示於表 9-2 和表 9-3 中。
程序：使用顯示度量資料的 metrics 子指令
本節描述使用 metrics 子指令報告度量資訊的程序。
若要使用 metrics 子指令
度量輸出：imqcmd metrics
本節顯示用於代理程式範圍、連接服務和目標度量的度量子指令輸出範例。
代理程式範圍度量。 若要取得訊息和封裝每隔 10 秒流入和流出代理程式的速率，請使用metrics bkr 子指令：
imqcmd metrics bkr -m rts -int 10 -u admin -p admin
此指令會產生與以下相似的輸出 (請參閱表 9-8 中的資料說明)：
連接服務度量。 若要取得由 jms 連接服務處理之訊息和封包的累積總數，請使用 metrics svc 子指令：
imqcmd metrics svc -n jms -m ttl -u admin -p admin
此指令會產生與以下相似的輸出 (請參閱表 9-9 中的資料說明)：
-------------------------------------------------
Msgs Msg Bytes Pkts Pkt Bytes
In Out In Out In Out In Out
-------------------------------------------------
164 100 120704 73600 282 383 135967 102127
657 100 483552 73600 775 876 498815 149948
目標度量。 若要取得有關目標的度量資訊，請使用 metrics dst 子指令：
imqcmd metrics dst -t q -n XQueue -m ttl -u admin -p admin
此指令會產生與以下相似的輸出 (請參閱表 9-10 中的資料說明)：
-----------------------------------------------------------------------------
Msgs Msg Bytes Msg Count Total Msg Bytes (k) Largest
In Out In Out Current Peak Avg Current Peak Avg Msg (k)
-----------------------------------------------------------------------------
200 200 147200 147200 0 200 0 0 143 71 0
300 200 220800 147200 100 200 10 71 143 64 0
300 300 220800 220800 0 200 0 0 143 59 0
若要取得目標的使用者相關資訊，請使用以下 metrics dst 子指令：
imqcmd metrics dst -t q -n SimpleQueue -m con -u admin -p admin
此指令會產生與以下相似的輸出 (請參閱表 9-10 中的資料說明)：
------------------------------------------------------------------
Active Consumers Backup Consumers Msg Count
Current Peak Avg Current Peak Avg Current Peak Avg
------------------------------------------------------------------
1 1 0 0 0 0 944 1000 525
imqcmd query
imqcmd query 的語法和選項顯示於表 9-4 中，並隨附該指令提供的度量資料說明。
表 9-4 imqcmd query 子指令語法
子指令語法
提供的度量資料
query bkr
[-b hostName:port]
[-int interval]
[-msp numSamples]目前儲存於代理程式記憶體與永久性倉庫之訊息數目和訊息容量的資訊 (請參閱「顯示代理程式資訊」)
或
metrics svc -n serviceName
[-b hostName:port]
[-int interval]
[-msp numSamples]目前已配置執行緒的數目和指定連接服務之連接數目的資訊 (請參閱「顯示連接服務資訊」)
或
metrics dst -t destType
-n destName
[-b hostName:port]
[-int interval]
[-msp numSamples]目前產生者、作用中和備份使用者，與用於指定目標中記憶體和永久性倉庫中儲存的訊息和訊息容量的資訊 (請參閱「顯示目標資訊」)
備註
因為 imqcmd query 提供有限的度量資料，所以未在(more...)上的「度量資料的說明,」小節中的表格列出此工具。
Message Queue 代理程式日誌檔
Message Queue 記錄程式會取得代理程式程式碼產生的資訊、除錯程式和度量產生器，並將資訊寫入一些輸出通道：標準輸出 (主控台)、日誌檔及 Solaris™ 平台上的 syslog (系統日誌) 常駐程式。「記錄程式」中說明了此記錄程式。
您可以指定記錄程式收集的資訊類型，以及寫入每個輸出通道的類型。要特別注意的是，您可以指定您要寫入日誌檔的度量資訊。
程序：使用代理程式日誌檔報告度量資訊
本節描述使用代理程式日誌檔報告度量資訊的程序。如需配置記錄程式的一般資訊，請參閱「記錄」。
若要使用日誌檔報告度量資訊
度量輸出：日誌檔
以下顯示輸出到日誌檔的代理程式度量輸出範例 (請參閱表 9-7 和表 9-8 中度量資料的說明)：
[21/Jul/2003:11:21:18 PDT]
Connections: 0 JVM Heap: 8323072 bytes (7226576 free) Threads: 0 (14-1010)
In: 0 msgs (0bytes) 0 pkts (0 bytes)
Out: 0 msgs (0bytes) 0 pkts (0 bytes)
Rate In: 0 msgs/sec (0 bytes/sec) 0 pkts/sec (0 bytes/sec)
Rate Out: 0 msgs/sec (0 bytes/sec) 0 pkts/sec (0 bytes/sec)
基於訊息監視的 API
Message Queue 提供度量監視功能，此功能可讓代理程式將度量資料寫入 JMS 訊息，接著並根據包含於訊息中的度量資訊類型，將其傳送到其中一個度量主題目標。
您可以藉由寫入訂閱度量主題目標、使用目標中的訊息並處理訊息中度量資訊的用戶端應用程式，來存取此度量資訊。「度量資訊產生者 (企業版)」中描述了一般機制。
總共有 5 個度量主題目標。表 9-5中顯示了這些目標的名稱，和發送到每個目標的度量訊息類型。
表 9-5 度量主題目標
主題名稱
度量訊息的類型
mq.metrics.broker
代理程式度量
mq.metrics.jvm
Java 虛擬機器度量
mq.metrics.destination_list
目標及其類型的清單
mq.metrics.destination.queue.
monitoredDestinationName用於指定名稱之佇列的目標度量
mq.metrics.destination.topic.
monitoredDestinationName用於指定名稱之主題的目標度量
程序：設定基於訊息的監視
本節描述使用基於訊息監視功能，收集度量資訊的程序。程序包括用戶端部署和管理工作。
若要設定基於訊息的監視
- 寫入度量監視用戶端。
請參閱「Message Queue Java 用戶端開發人員南」，以取得設計用戶端訂閱度量主題目標、使用度量訊息並從這些訊息擷取度量資料的說明。
- 藉由設定 config.properties 檔案中的代理程式特性值，配置代理程式的度量訊息產生者：
- 設定任何您要在度量主題目標上的存取控制。
請參閱以下「安全性與存取注意�,ⅱ窗v中的說明。
- 啟動度量監視用戶端。
使用者訂閱度量主題時，即會自動建立度量主題目標。一旦建立度量主題，代理程式度量訊息產生者會開始傳送度量訊息到度量主題。
安全性與存取注意事項
有兩個限制度量主題目標存取的原因：
由於這些考量，所以建議您限制度量主題目標的存取。
監視用戶端必須遵守與其他用戶端相同的認證和授權控制。只有 Message Queue 使用者儲存庫中的使用者可以連接到代理程式。
您可以藉由存取控制特性檔限制存取特定度量主題目標，藉以提供額外保護，如「授權使用者： 存取控制特性檔案」中所述。
例如，以下 accesscontrol.properties 檔案中的項目會拒絕除了 user1 和 user2 以外的其他任何人存取 mq.metrics.broker 度量主題。
以下項目僅允許使用 user3 監視主題 t1。
topic.mq.metrics.destination.topic.t1.consume.deny.user=*
topic.mq.metrics.destination.topic.t1.consume.allow.user=user3
根據度量資料關聯，您也可以使用加密連接，將度量監視用戶端連接到代理程式。如需使用加密連接的資訊，請參閱「加密：使用基於 SSL 的服務 (企業版)」。
度量輸出：度量訊息
您使用基於訊息監視的 API 取得的度量資料輸出，為您寫入度量監視用戶端的函數。您僅受限於代理程式中度量產生器提供的資料。如需此資料的完整清單，請參閱「度量資料的說明」。
選擇正確的監視工具
前面章節中提及的每個監視工具皆有其優點和缺點。
例如，使用 imqcmd metrics 指令可讓您快速取得符合您需求的資訊，但在查看歷程資訊或有計劃處理資料時會稍有難度。
相反地，日誌檔會提供長期的度量資料記錄，但日誌檔中的資訊會難以剖析成有意義的資訊。
基於訊息監視的 API 可讓您輕易擷取您所需的資訊，進而處理資訊、有計劃處理或格式化資料、呈現圖表或傳送警示；然而，您必須寫入自訂的應用程式以擷取和分析資料。
此外，每個工具皆會收集由代理程式產生且稍微不同的度量資訊子集。如需度量資料為何種監視工具所收集的資訊，請參閱「度量資料的說明」。
表 9-6 比較不同工具，顯示每個工具的優缺點。
表 9-6 度量監視工具的優缺點
標準資訊
監視工具優點
缺點
imqcmd metrics
遠端監視
便於抽查
在指令選項中設定報告間隔時間；可即時變更
易於選取偏好的特定資料
以簡單表格格式呈現的資料
沒有取得所有資料的單一指令
難以有計劃分析資料
未建立歷程記錄
難以查看歷程趨勢
日誌檔
固定取樣
建立歷程記錄
需要配置代理程式特性；必須關閉並重新啟動代理程式才可生效
僅本地監視
資料格式難以讀取或剖析；沒有剖析工具
無法即時變更報告間隔時間；所有度量資料的報告間隔時間皆相同
不提供彈性選取資料
僅代理程式度量；不包括目標和連接服務度量
若間隔時間過短可能會影響效能
基於訊息監視的 API
遠端監視
易於選取偏好的特定資料
可透過電腦分析資料並以任何格式呈現
需要配置代理程式特性；必須關閉並重新啟動代理程式才可生效
您必須寫入您自己的度量監視用戶端
無法即時變更報告間隔時間；所有度量資料的報告間隔時間皆相同
度量資料的說明
可以將代理程式報告的度量資訊分為以下幾個種類：
以下各節描述每個種類中可用的度量資料。如需以下表格中提及之監視工具的資訊，請參閱「監視工具」。
JVM 度量
表 9-7 列出並描述代理程式產生用於代理程式處理 JVM 堆疊的度量資料，並顯示可使用不同度量監視工具取得的資料類型。
表 9-7 JVM 度量
度量數目
說明
imqcmd metrics bkr
(度量類型)日誌檔
度量訊息
(度量主題)1JVM 堆疊：
可用記憶體可用記憶體的容量可在 JVM 堆疊中使用。
需要
(cxn)需要
需要
(...jvm)JVM 堆疊：
總記憶體目前的 JVM 堆疊容量
需要
(cxn)需要
需要
(...jvm)JVM 堆疊：
最大記憶體可增加 JVM 堆疊容量的最大值。
不需要
需要2
需要
(...jvm)
2僅在代理程式啟動時顯示。
代理程式範圍度量
表 9-8 列出並描述代理程式報告關於代理程式範圍度量資訊的資料。它亦顯示使用不同度量監視工具可取得的資料類型。
表 9-8 代理程式範圍度量
度量數目
說明
imqcmd metrics bkr
(度量類型)日誌檔
度量訊息
(度量主題)1連接資料
連接數目
目前開啟至代理程式連接的數目
需要
(cxn)需要
需要
(...代理程式)執行緒數目
目前使用中的執行緒數目
需要
(cxn)需要
不需要
最小執行緒數目
一旦到達執行緒數目，便會在執行緒儲存區中維護執行緒數目，以供連接服務使用
需要
(cxn)需要
不需要
最大執行緒數目
一旦超過執行緒數目，便不會再新增執行緒到執行緒儲存區，以供連接服務使用
需要
(cxn)需要
不需要
儲存的訊息資料
訊息數目
目前儲存於代理程式記憶體和永久性倉庫的 JMS 訊息數目
不需要
使用 query bkr不需要
需要
(...代理程式)訊息總容量
目前儲存於代理程式記憶體和永久性倉庫的 JMS 訊息容量
不需要
使用 query bkr不需要
需要
(...代理程式)訊息流量資料
流入的訊息數目
從上次代理程式啟動後，流入代理程式的 JMS 訊息數目
需要
(ttl)需要
需要
(...代理程式)流入的訊息容量
從上次代理程式啟動後，流入代理程式的 JMS 訊息容量
需要
(ttl)需要
需要
(...代理程式)流入的封包數目
從上次代理程式啟動後，流入代理程式的封包數目；包括 JMS 訊息和控制訊息
需要
(ttl)需要
需要
(...代理程式)流入的封包容量
從上次代理程式啟動後，流入代理程式的封包容量；包括 JMS 訊息和控制訊息
需要
(ttl)需要
需要
(...代理程式)流出的訊息數目
從上次代理程式啟動後，流出代理程式的 JMS 訊息數目
需要
(ttl)需要
需要
(...代理程式)流出的訊息容量
從上次代理程式啟動後，流出代理程式的 JMS 訊息容量
需要
(ttl)需要
需要
(...代理程式)流出的封包數目
從上次代理程式啟動後，流出代理程式的封包數目；包括 JMS 訊息和控制訊息。
需要
(ttl)需要
需要
(...代理程式)流出的封包容量
從上次代理程式啟動後，流出代理程式的封包容量；包括 JMS 訊息和控制訊息。
需要
(ttl)需要
需要
(...代理程式)流入訊息的速率
目前流入代理程式的 JMS 訊息速率
需要
(rts)需要
不需要
流入訊息容量的速率
目前流入代理程式之 JMS 訊息容量的速率
需要
(rts)需要
不需要
流入的封包速率
目前流入代理程式的封包速率；包括 JMS 訊息和控制訊息
需要
(rts)需要
不需要
流入封包容量的速率
目前流入代理程式之封包容量的速率；包括 JMS 訊息和控制訊息
需要
(rts)需要
不需要
流出訊息的速率
目前流出代理程式的 JMS 訊息速率
需要
(rts)需要
不需要
流出訊息容量的速率
目前流出代理程式之 JMS 訊息容量的速率
需要
(rts)需要
不需要
流出封包的速率
目前流出代理程式的封包速率；包括 JMS 訊息和控制訊息
需要
(rts)需要
不需要
流出封包容量的速率
目前流出代理程式之封包容量的速率；包括 JMS 訊息和控制訊息
需要
(rts)需要
不需要
目標資料
目標數目
代理程式中實體目標的數目
不需要
不需要
需要
(...代理程式)
連接服務度量
表 9-9 列出並描述代理程式報告用於個別連接服務的度量資料。它亦顯示使用不同度量監視工具可取得的資料類型。
表 9-9 連接服務度量
度量數目
說明
imqcmd metrics svc
(度量類型)日誌檔
度量訊息
(度量主題)連接資料
連接數目
目前開啟連接的數目
需要
(cxn)
亦可使用 query svc不需要
不需要
執行緒數目
目前使用中的執行緒數目，為所有連接服務的加總
需要
(cxn)
亦可使用 query svc不需要
不需要
最小執行緒數目
一旦到達執行緒數目，便會在執行緒儲存區中維護執行緒數目，以供連接服務使用；此數目為所有連接服務的加總
需要
(cxn)不需要
不需要
最大執行緒數目
一旦超過執行緒數目，便不會再新增執行緒到執行緒儲存區，以供連接服務使用；此數目為所有連接服務的加總
需要
(cxn)不需要
不需要
訊息流量資料
流入的訊息數目
從上次代理程式啟動後，流入連接服務的 JMS 訊息數目
需要
(ttl)不需要
不需要
流入的訊息容量
從上次代理程式啟動後，流入連接服務的 JMS 訊息容量
需要
(ttl)不需要
不需要
流入的封包數目
從上次代理程式啟動後，流入連接服務的封包數目；包括 JMS 訊息和控制訊息。
需要
(ttl)不需要
不需要
流入的封包容量
從上次代理程式啟動後，流入連接服務的封包容量；包括 JMS 訊息和控制訊息。
需要
(ttl)不需要
不需要
流出的訊息數目
從上次代理程式啟動後，流出連接服務的 JMS 訊息數目
需要
(ttl)不需要
不需要
流出的訊息容量
從上次代理程式啟動後，流出連接服務的 JMS 訊息容量
需要
(ttl)不需要
不需要
流出的封包數目
從上次代理程式啟動後，流出連接服務的封包數目；包括 JMS 訊息和控制訊息。
需要
(ttl)不需要
不需要
流出的封包容量
從上次代理程式啟動後，流出連接服務的封包容量；包括 JMS 訊息和控制訊息。
需要
(ttl)不需要
不需要
流入訊息的速率
目前通過連接服務流入代理程式的 JMS 訊息速率
需要
(rts)不需要
不需要
流入訊息容量的速率
目前流入連接服務之 JMS 訊息容量的速率
需要
(rts)不需要
不需要
流入的封包速率
目前流入連接服務的封包速率；包括 JMS 訊息和控制訊息
需要
(rts)不需要
不需要
流入封包容量的速率
目前流入連接服務之封包容量的速率；包括 JMS 訊息和控制訊息
需要
(rts)不需要
不需要
流出訊息的速率
目前流出連接服務的 JMS 訊息速率
需要
(rts)不需要
不需要
流出訊息容量的速率
目前流出連接服務之 JMS 訊息容量的速率
需要
(rts)不需要
不需要
流出封包的速率
目前流出連接服務的封包速率；包括 JMS 訊息和控制訊息
需要
(rts)不需要
不需要
流出封包容量的速率
目前流出連接服務之封包容量的速率；包括 JMS 訊息和控制訊息
需要
(rts)不需要
不需要
目標度量
表 9-9 列出並描述代理程式報告用於個別目標的度量資料。它亦顯示使用不同度量監視工具可取得的資料類型。
表 9-10 目標度量
度量數目
說明
imqcmd metrics dst
(度量類型)日誌檔
度量訊息
(度量主題)1使用者資料
作用中使用者的數目
目前作用中使用者的數目
需要
(con)不需要
需要
(...destName)作用中使用者的平均數目
從上次代理程式啟動後，作用中使用者的平均數目
需要
(con)不需要
需要
(...destName)作用中使用者的尖峰數目
從上次代理程式啟動後，作用中使用者的尖峰數目
需要
(con)不需要
需要
(...destName)備份使用者的數目
目前備份使用者的資料 (僅適用於佇列)
需要
(con)不需要
需要
(...destName)備份使用者的平均數目
從上次代理程式啟動後，備份使用者的平均數目 (僅適用於佇列)
需要
(con)不需要
需要
(...destName)備份使用者的尖峰數目
從上次代理程式啟動後，備份使用者的尖峰數目 (僅適用於佇列)
需要
(con)不需要
需要
(...destName)儲存的訊息資料
訊息數目
目前儲存於目標記憶體和永久性倉庫的 JMS 訊息數目
需要
(con)
(ttl)
(rts)
亦可使用 query dst不需要
需要
(...destName)訊息平均數目
從上次代理程式啟動後，儲存於目標記憶體和永久性倉庫中的 JMS 訊息平均數目
需要
(con)
(ttl)
(rts)不需要
需要
(...destName)訊息尖峰數目
從上次代理程式啟動後，儲存於目標記憶體和永久性倉庫中的 JMS 訊息尖峰數目
需要
(con)
(ttl)
(rts)不需要
需要
(...destName)訊息總容量
目前儲存於目標記憶體和永久性倉庫的 JMS 訊息容量
需要
(ttl)
(rts)
亦可使用 query dst不需要
需要
(...destName)訊息的總平均容量
從上次代理程式啟動後，儲存於目標記憶體和永久性倉庫中的 JMS 訊息平均容量
需要
(ttl)
(rts)不需要
需要
(...destName)訊息的總尖峰容量
從上次代理程式啟動後，儲存於目標記憶體和永久性倉庫中的 JMS 訊息尖峰容量
需要
(ttl)
(rts)不需要
需要
(...destName)訊息的尖峰容量
從上次代理程式啟動後，目標接收的單一訊息中 JMS 訊息的尖峰容量
需要
(ttl)
(rts)不需要
需要
(...destName)訊息流量資料
流入的訊息數目
從上次代理程式啟動後，流入目標的 JMS 訊息數目
需要
(ttl)不需要
需要
(...destName)流入的訊息容量
從上次代理程式啟動後，流入目標的 JMS 訊息容量
需要
(ttl)不需要
需要
(...destName)流出的訊息數目
從上次代理程式啟動後，流出目標的 JMS 訊息數目
需要
(ttl)不需要
需要
(...destName)流出的訊息容量
從上次代理程式啟動後，流出目標的 JMS 訊息容量
需要
(ttl)不需要
需要
(...destName)流入訊息的速率
目前流入目標的 JMS 訊息速率
需要
(rts)不需要
不需要
流出訊息的速率
目前流出目標式的 JMS 訊息速率
需要
(rts)不需要
不需要
流入訊息容量的
速率目前流入目標之 JMS 訊息容量的速率
需要
(rts)不需要
不需要
流出訊息容量的
速率目前流出目標之 JMS 訊息容量的速率
需要
(rts)不需要
不需要
磁碟使用資料
保留的磁碟空間
基於檔案的目標倉庫中，所有訊息記錄 (作用中或可用) 使用的磁碟空間 (以位元組為單位)
需要
(dsk)不需要
需要
(...destName)使用的磁碟空間
基於檔案的目標倉庫中，作用中訊息記錄使用的磁碟空間 (以位元組為單位)
需要
(dsk)不需要
需要
(...destName)磁碟使用率
使用的磁碟空間除以保留的磁碟空間所得之商數比率越高表示有越多磁碟空間被用來保留作用中訊息
需要
(dsk)不需要
需要
(...destName)
排解效能問題使用 Message Queue 服務支援應用程式時會發生一些效能問題。這些問題包括：
以下將描述每個問題的可能原因和解決方案。
問題：用戶端無法建立連接
徵兆：
可能原因：
若要確認此問題的原因：
檢查所有連接服務的狀態：
如果連接服務狀態顯示如下 unknown (未知) 或 paused (暫停中)，那麼用戶端無法使用服務建立連接。
若要解決此問題：
若要正確配置 SSL 服務，請參閱「透過 TCP/IP 設定基於 SSL 的服務」。
- 如果連接服務狀態顯示為 paused (暫停中)，那麼會繼續服務 (請參閱「暫停與繼續連接服務」)。
若要確認此問題的原因：
檢查代理程式日誌中是否有以下項目：警告 [B3004]：沒有可用於服務上處理新連接的執行緒...關閉新的連接。
並檢查連接服務上的連接數目和目前使用中的執行緒數目：
每個連接均需要兩個執行緒：一個用於進來的訊息，另一個用於外送的訊息 (請參閱「執行緒儲存區管理程式」)。
若要解決此問題：
- 如果您使用專用執行緒儲存區模型(imq.service_name. threadpool_model=dedicated)，那麼最大的連接數目為執行緒儲存區中最大執行緒數目的一半。因此，若要增加連接數目，請增加執行緒儲存區的容量 (imq.service_name.max_threads) 或切換為共用執行緒儲存區模型。
- 如果您使用共用執行緒儲存區模型 (imq.service_name. threadpool_model=shared)，那麼最大的連接數目為以下兩種特性產品的一半：連接監視限制 (imq.service_name.connectionMonitor_limit) 和最大執行緒數目 (imq.service_name.max_threads)。因此，若要增加連接數目，請增加執行緒儲存區的容量或增加連接監視限制。
- 可支援的連接數目 (或連接上的流量) 最終會到達輸入/輸出限制。在此情況下，請使用多重代理程式叢集 (請參閱「使用叢集 (企業版)」)，以分散叢集中代理程式實例上的連接。
- Solaris 或 Linux 平台上要求用於連接數目的檔案描述元太少 (請參閱「定義作業系統檔案描述元限制」)。
TCP 儲存區會在連接埠對映器拒絕其他請求前，限制同時儲存在系統儲存區內的連接請求數目 (imq.portmapper.backlog)。(在 Windows 平台上有程式內定的儲存區限制：Windows Desktop 的數目為 5，Windows Server 的數目為 200。)
因為不經常有高數目的同時連接請求，所以因儲存區限制的請求拒絕通常為短暫現象。
若要確認此問題的原因：
檢查代理程式日誌，查看在拒絕其他連接請求時，是否在幾乎相同的時間接受其他連接請求。拒絕的連接請求會傳回 java.net.ConnectException：拒絕連接。
若要解決此問題：
可以用以下方法來解決 TCP 儲存區限制：
驗證可能會因為錯誤密碼而失敗，因為沒有使用者進入使用者儲存庫的項目，或因為使用者沒有存取連接服務的許可權。
若要確認此問題的原因：
檢查代理程式日誌中是否有禁用錯誤訊息的項目。這表示有驗證錯誤，但不表示為問題發生的原因。
若要解決此問題：
- 如果使用者儲存庫中沒有用於使用者的項目，那麼請將使用者新增到使用者儲存庫 (請查看「寫入和管理使用者儲存庫」)。
- 如果使用的密碼錯誤，請提供正確的密碼。
- 如果存取控制特性未正確設定，請編輯存取控制特性檔案，以取得連接服務許可權 (請參閱「連接存取控制」)。
問題：連接流量過慢
徵兆：
- 訊息流量未符合預期速度。
- 支援連接到代理程式的數目不受到限制，如「問題：用戶端無法建立連接」所述，但訊息輸入/輸出速率受到限制。
可能原因：
- 連接服務協定的速度原本就比 TCP 的速度慢。例如，基於 SSL 或基於 HTTP 協定的速度會較 TCP 的速度慢 (請參閱圖 9-5)。
若要確認此問題的原因：
如果您使用基於 SSL 或基於 HTTP 的協定，請嘗試使用 TCP 並比較發送時間。
若要解決此問題：
應用程式需求通常會表示要使用的協定，這是您可以參考的一點。除此之外，您還可以嘗試調整協定，如 「調整傳輸協定」 所述。
若要確認此問題的原因：
嘗試調整協定，並查看是否有何差異。
若要解決此問題：
嘗試調整協定，如「調整傳輸協定」所述。
若要確認此問題的原因：
如果上述原因都不是造成連接流量速度過慢的原因，則請查閱圖 9-1，找出其他可能的瓶頸，並檢查是否有與以下問題相關的徵兆：
若要解決此問題：
依照以上問題排解各節提供的問題解決方針。
問題：用戶端無法建立訊息產生者
徵兆：
可能原因：
若要確認此問題的原因：
代理程式拒絕新的產生者時，代理程式會傳回 JMSSecurityException [C4076]：用戶端沒有在目標上建立產生者的許可權，在代理程式日誌中產生以下項目：[B2041]：在目標上的產生者被拒絕 和 [B4051]：禁用 guest。
若要解決此問題：
變更存取控制特性，以允許使用者產生訊息 (請參閱「目標存取控制」)。
問題：訊息產生延遲或過慢
徵兆：
可能原因：
目標中的訊息數目或訊息容量到達配置限制時，代理程式會依指定的限制行為，嘗試節省記憶體資源。以下限制行為會降低訊息產生者的速度：
同樣地，代理程式範圍記憶體 (用於所有目標) 中的訊息數目或訊息容量到達配置限制時，代理程式會藉由拒絕最新訊息，嘗試節省記憶體資源。
再者，到達系統記憶體限制時 (因為目標或代理程式範圍的限制未正確設定)，代理程式會採取越來越重要的動作，以防記憶體超過負載，包括減低訊息產生者的速度。
如需這些機制的說明，請參閱「管理記憶體資源和訊息流量」。
若要確認此問題的原因：
代理程式因配置的訊息限制拒絕訊息時，代理程式會傳回 JMSException [C4036]：伺服器發生錯誤，並在代理程式日誌中產生項目：警告 [B2011]：儲存來自 IMQconn 的 JMS 訊息失敗，並隨附一個訊息，說明已到達限制：
一般而言，您可以在拒絕訊息前檢查訊息限制條件，方法為查詢目標和代理程式、檢查配置的訊息限制設定，並使用 imqcmd 指令監視目前目標 (或作為整體代理程式) 中的訊息數目和訊息容量 (請個別查看表 9-10 和表 9-8)。
若要解決此問題：
有數種方法可以解決訊息儲存時造成產生者速度變慢的問題。
如果代理程式無法存取資料倉庫或將永久性訊息寫入資料倉庫，則表示生產型用戶端被封鎖。這種情況亦會在目標或代理程式範圍訊息到達限制時發生，如上所述。
若要確認此問題的原因：
如果代理程式無法寫入資料倉庫，則會在代理程式日誌中產生以下其中一個項目：[B2011]：儲存來自 connectionID 的 JMS 訊息失敗... 或 [B4004]：無法存留訊息 messageID...
若要解決此問題：
- 在內建持續性的情況下，請嘗試增加基於檔案的資料倉庫的磁碟空間。
- 在使用 JDBC 相容資料倉庫的情況下，請檢查是否正確配置外掛持續性 (請參閱附錄 B「設定外掛持續性」)。如果已正確配置，請洽詢您的資料庫管理員以排解其他資料庫問題。
由於連接速度慢或訊息伺服器緩慢 (因高 CPU 使用率或記憶體資源不足所引起)，代理程式可能需要更多時間來確認持久性訊息的接收，且時間超過連線工廠的 imqAckTimeout 屬性所允許的值。
若要確認此問題的原因：
如果超過 imqAckTimeout 的值，代理程式會傳回 JMSException [C4000]：資料封包確認失敗。
若要解決此問題：
變更 imqAckTimeout 連線工廠屬性值 (請參閱「連線工廠受管理物件屬性」)。
若要確認此問題的原因：
若要解決此問題：
調整 JVM (請查看「Java 虛擬機器調整」)。
問題：訊息儲存在訊息伺服器中
徵兆：
可能原因：
如果可發送訊息的作用中使用者太少，那麼可以在訊息累積時儲存佇列目標。此情況會因以下任何一種原因而發生：
若要確認此問題的原因：
若要判斷無法使用使用者的原因，請檢查目標上作用中使用者的數目：
若要解決此問題：
您可以根據無法使用使用者的原因，採取以下任何一個動作：
- 啟動其他使用用戶端，以建立更多用於佇列的作用中使用者。
- 調整 imq.consumerFlowLimit 代理程式特性，以最佳化至多個使用者的佇列發送 (請參閱「多重使用者佇列效能」)。
- 指定用於佇列的訊息限制和訊息行為屬性 (請參閱表 6-10)。例如，您可以指定可刪除記憶體中累積訊息的 REMOVE_OLDEST 和 REMIOVE_LOW_PRIOROTY 限制行為。
- 從對應的目標清除所有訊息 (請參閱「清除目標」)。
- 時間訊息的限制可保留在記憶體中：您可以重新寫入生產型用戶端，以設定每個訊息的存在時間值。另外，還可置換用於所有產生者共用連接的任何設定值，方法為設定 imqOverrideJMSExpiration 和 imqJMSExpiration 連線工廠屬性 (請參閱表 7-3)。
在此情況下，主題用戶或佇列接收者使用訊息的速度，會比產生者傳送訊息的速度慢。因為此不平衡現象，所以會儲存一個或多個包含訊息的目標。
若要確認此問題的原因：
檢查流入和流出代理程式的訊息速率：
接著檢查每個個別目標的流量速率：
若要解決此問題：
- 最佳化使用用戶端程式碼。
- 增加用於佇列目標的作用中使用者數目 (請參閱「多重使用者佇列效能」)。
兩個影響用戶端確認處理的因素：
若要確認此問題的原因：
檢查與封包流量相關的訊息流量。如果每秒的封包數目與訊息數目不成比例，那麼用戶端確認可能有問題。
還要檢查用戶端是否接收到以下訊息 JMSException [C4000]：封包確認失敗。
若要解決此問題：
- 修改用戶端使用的確認模式，例如切換為 DUPS_OK_ACKNOWLEDGEMENT 或 CLIENT_ACKNOWLEDGEMENT。
- 如果使用 CLIENT_ACKNOWLEDGEMENT 或異動階段作業，請將更大的訊息數目設為單一確認的群組。
- 調整使用者和連接流量控制參數 (請參閱「用戶端運行時間訊息流量調整」)。
問題：訊息伺服器的流量不穩定
徵兆：
可能原因：
因為未正確設定目標與代理程式限制，代理程式會採取越來越重要的動作，以防記憶體超過負載。另外，在清除訊息儲存前，會導致代理程式運作緩慢。
若要確認此問題的原因：
檢查記憶體不足情況下的代理程式日誌 ([B1089]：在記憶體不足的條件下，代理程式正嘗試釋放資源)，並隨附一個項目，描述新的記憶體狀態和使用的記憶體總數。
還要檢查 JVM 堆疊中可用的記憶體：
JVM 記憶體總數接近最大 JVM 記憶體值時，可用記憶體會不足。
若要解決此問題：
- 調整 JVM (請查看「Java 虛擬機器調整」)。
- 增加系統交換空間。
問題：訊息未送達使用者
徵兆：
可能原因：
如果時鐘不同步，那麼代理程式計算訊息的存在時間會發生錯誤，如此會導致訊息逾時並被刪除。
若要確認此問題的原因：
檢查所有電腦的時鐘。
若要解決此問題：
同步化時鐘 (請參閱「系統時鐘設定」)。
調整您的配置以改善效能系統調整
以下各節描述您可對作業系統、JVM 和連接協定所做的調整。
Solaris 調整：CPU 使用率、分頁/交換/磁碟 I/O
請參閱您系統的說明文件來調整您的作業系統。
Java 虛擬機器調整
依預設，代理程式會使用 192 MB 的 JVM 堆疊大小。此容量對大量的訊息負載通常過小，所以應增加其大小。
當代理程式將要耗盡 Java 物件使用的 JVM 堆疊儲存區空間時，會使用各種技術 (如流量控制和訊息交換) 來釋放記憶體。在極端情況下，它甚至會關閉用戶端連接以釋放記憶體，並降低訊息的流入量。因此，最好將最大 JVM 堆疊儲存區空間設定得足夠大，以避免發生此類情況。
但是，如果將最大 Java 堆疊儲存區空間設定得過大 (相對於系統實體記憶體)，代理程式會持續增加 Java 堆疊儲存區空間，直至整個系統的記憶體用完。這會導致效能降低、不可預料的代理程式當機，和/或影響系統上執行的其他應用程式和服務的運作。一般而言，您需要允許足夠用於作業系統和機器上其他執行應用程式的實體記憶體。
一般說來，最好是先評估正常時和高峰時的系統記憶體足跡，然後再配置 Java 堆疊儲存區容量，使其足以提供良好的效能，但又不會太大，以至出現系統記憶體問題。
若要變更代理程式最小和最大的堆疊大小，請在啟動代理程式時使用 -vmargs 指令行選項。例如：
此指令會將啟動時的 Java 堆疊大小設為 256MB，且將最大的 Java 堆疊大小設為 1GB。
- 在 Solaris 上，如果經由 /etc/rc (即 /etc/init.d/imq) 啟動代理程式，則請在 /etc/imq/imqbrokerd.conf 檔案中指定代理程式指令行引數。請查看檔案中的註解，以取得更多資訊。
- 在 Windows 上，如果將代理程式作為 Windows 服務啟動，則請使用 -vmargs 選項將 JVM 引數指定到 imqsvcadmin 安裝指令。請參閱「服務管理員公用程式 (imqsvcadmin)」。
在任何情況下，請藉由檢查代理程式的日誌檔或使用
imqcmd metrics bkr -m cxn 指令來驗證設定值。調整傳輸協定
一旦選擇符合應用程式需求的協定，則額外調整 (以選定的協定為基礎) 可能會改善效能。
可以使用以下三個代理程式特性來修改協定效能：
針對 TCP 和 SSL 協定，這些特性會影響用戶端和代理程式間訊息發送的速度。針對 HTTP 和 HTTPS 協定，這些特性會影響 Message Queue 通道 Servlet (在 Web Server 上執行) 和代理程式間的訊息發送速度。針對 HTTP/HTTPS 協定，有其他特性可以影響效能 (請參閱「HTTP/HTTPS 調整」)。
將會在以下各節描述協定調整特性。
nodelay
nodelay 特性會影響用於既定協定的 Nagle 演算法 (TCP/IP 上的 TCP_NODELAY 套接級別選項)。Nagle 演算法可使用慢速連接，例如廣域網路 (WAN)，來改善系統上的 TCP 效能。
使用該演算法時，TCP 會嘗試阻止一些小型資料區塊傳送到遠端系統 (藉由將資料隨附於較大封包中)。如果寫入套接的資料未填滿所需緩衝區大小，那麼協定會在緩衝區填滿或特定延遲時間結束前，延遲傳送封包。一旦緩衝區為填滿狀態或發生逾時，即會傳送封包。
針對大部分的訊息傳送應用程式，在傳送封包時沒有延遲即表示效能為最佳狀態 (未啟用 Nagle 演算法)。這是因為大部分用戶端與代理程式間的互動為請求/確認互動：用戶端傳送資料封包給代理程式且等待確認。例如，典型的互動包括：
針對這些互動，大部分的封包小於緩衝區大小。這表示如果使用 Nagle 演算法，代理程式在傳送確認到使用者時，會延遲數毫秒。
但是，Nagle 演算法會在連接速度緩慢和不需代理程式確認的情況下改善效能。這可能是用戶端傳送非永久性訊息，或用戶端確認未經代理程式確認的情況 (DUPS_OK_ACKNOWLEDGE 階段作業)。
inbufsz/outbufsz
inbufsz 特性會設定輸入串流上的緩衝區大小，輸入串流可讀取來自套接的資料。同樣地，outbufsz 會設定輸出串流的緩衝區大小，輸出串流為代理程式用來將資料寫入套接。
一般而言，兩個參數值皆應稍微大於接收或傳送的平均封包大小。根據經驗，請將這些特性值設定為比平均封包大小多 1K (將近 1K)。
舉例來說，如果代理程式接收內文大小為 1K 的封包，那麼封包 (訊息內文 + 標頭 + 特性) 的總容量則約為 1,200 個位元組一個 2K (2,048 個位元組) 的 inbufsz 即可產生適當效能。
將 inbufsz 或 outbufsz 增加到超過此大小可能會稍微改善效能；但是，這可能會增加每個連接的所需記憶體。
圖 9-6 顯示在 1K 的封包上變更 inbufsz 的結果。
圖 9-7 在 1K (1,024 個位元組) 封包上變更 inbufsz 的效果
圖 9-8 顯示在 1K 的封包上變更 outbufsz 的結果。
圖 9-8 在 1K (1,024 個位元組) 封包上變更 outbufsz 的效果
HTTP/HTTPS 調整
除了前面兩節描述的一般特性，HTTP/HTTPS 效能受限於用戶端發出 HTTP 請求到管理 Message Queue 通道 Servlet 之 Web Server 的速度。
Web Server 可能需要最佳化，以便處理單一套接上的多個請求。使用 JDK 1.4 或更新版本，HTTP 至 Web Server 的連接會保持暢通 (至 Web Server 的套接保持開啟狀態)，以便在 Web Server 處理多個 HTTP 請求時，最小化 Web Server 使用的資源。如果在同一個用戶端應用程式上，使用 JDK 1.4 版的效能比使用較早 JDK 版次的效能低，那麼您可能需要調整 Web Server 保持連接暢通的配置參數，以改善效能。
除了對 Web Server 進行此類調整，您也可以調整用戶端輪詢 Web Server 的頻率。HTTP 為基於請求的協定。這表示使用基於 HTTP 協定的用戶端會定期檢查 Web Server，查看是否有等待訊息。imq.httpjms.http.pullPeriod 代理程式特性 (及其對應的 imq.httpsjms.https.pullPeriod 特性) 會指定 Message Queue 用戶端運行時間輪詢 Web Server 的頻率。
如果 pullPeriod 值為 -1 (預設值)，那麼用戶端運行時間會在前個請求傳回時馬上輪詢伺服器，以最大化個別用戶端的效能。因此，每個用戶端連接會獨占 Web Server 中的一個請求執行緒，這可能會過度使用 Web Server 資源。
如果 pullPeriod 值為負數，則用戶端運行時間會定期傳送請求到 Web Server，以查看是否有擱置的資料。在此情況下，用戶端不會獨占 Web Server 中的請求執行緒。因此，如果大量用戶端使用 Web Server，那麼您可能要將 pullPeriod 設為正值，以節省 Web Server 資源。
調整基於檔案的永久性倉庫
如需調整基於檔案的永久性倉庫，請參閱「內建持續性」。
代理程式調整
以下各節描述您可對代理程式特性進行的調整，並藉以改善效能。
記憶體管理：增加代理程式負載的穩定性
可以在目標對目標級別或系統範圍級別 (用於所有目標，整體) 上配置記憶體管理。
使用目標限制
如需目標限制的資訊，請參閱「管理目標」。
使用系統範圍限制
如果訊息產生者嘗試過度執行訊息使用者，那麼可能會在代理程式中累積訊息。代理程式包含一個在記憶體不足情況下，降低產生者速度和將訊息移出作用中記憶體的機制 (請參閱「管理記憶體資源和訊息流量」)，所以對代理程式可保留的訊息總數目 (和容量) 做出硬式限制是明智之舉。
藉由設定 imq.system.max_count 和 imq.system.max_size 代理程式特性可控制這些限制。請參閱「編輯實例配置檔案」或「imqbrokerd 選項的摘要」，以獲得設定代理程式特性的相關資訊。
例如：
imq.system.max_count=5000
以上定義的值表示代理程式最多只會保留 5,000 個未發送/未確認的訊息。如果傳送額外訊息，則會被代理程式拒絕。如果為永久性訊息，那麼產生者在嘗試傳送訊息時會發生異常。如果為非永久性訊息，那麼代理程式會直接丟棄訊息。
若要非永久性訊息如同永久性訊息一樣傳回異常，那麼請在用戶端使用的連線工廠物件上設定以下特性：
imqAckOnProduce = true
以上設定可能會降低傳送非永久性訊息至代理程式 (用戶端會在傳送下一個訊息前等待確認) 的效能，但是，這情況通常是可接受的，因為流入代理程式的訊息通常不是系統瓶頸。
當傳送訊息時傳回異常，用戶端應稍作暫停並試著再傳送一次。
多重使用者佇列效能
多重佇列使用者在佇列目標中處理訊息的效率，取決於可配置的佇列目標屬性，即作用中使用者數目 (maxNumActiveConsumers)，以及在單一批次中可發送至使用者的最大訊息數目 (consumerFlowLimit)。表 6-10 中描述了這些屬性。
若要達到最佳化訊息流量，必須有足以跟上用於佇列之訊息產生速率的作用中使用者數目，且必需路由佇列中的訊息，接著將訊息發送到作用中使用者。此方法會最大化訊息使用率。「佇列發送至多個使用者」中描述平衡多重使用者上訊息發送的一般機制。
如果訊息累積在佇列中，那麼作用中使用者數目可能會不足以處理訊息負載。也有可能發生以下情形：以批次大小發送到使用者的訊息會在使用者上進行備份。舉例來說，如果批次大小 (consumerFlowLimit) 過大，一個使用者可能會接收佇列中的所有訊息，而其他作用中使用者會收不到任何訊息。如果使用者處理速度非常快，這可能不會發生問題。
但是，如果使用者的速度相對較慢，那麼您必須將訊息平均分散給使用者，如此一來，批次大小也會變小。批次大小越小，發送訊息至使用者所需的耗用時間就越長。然而，針對處理速度慢的使用者，網路效能改善比率通常會使用小型的批次大小。
用戶端運行時間訊息流量調整
本節描述影響效能的流量控制行為 (請參閱「用戶端運行時間配置」)。請將這些行為配置為連線工廠受管理物件的屬性。如需設定連線工廠屬性的資訊，請參閱第 7 章「管理受管理物件」
訊息流量計數
用戶端傳送和接收的訊息 (JMS 訊息) 與 Message Queue 控制訊息，皆會忽略相同用戶端與代理程式間的連接。如果 JMS 訊息發送阻擋控制訊息，則會造成控制訊息 (例如代理程式確認) 發送的延遲。若要避免此擁塞情形，Message Queue 要計算連接上的 JMS 訊息流量。
將 JMS 訊息分為幾個批次 (以 imqConnectionFlowCount 特性指定)，如此一來，會在發送批次後暫停 JMS 訊息發送並在發送擱置控制訊息後發送一組數字。控制訊息形成佇列後，發送 JMS 訊息的其他批次時會重複此循環。
如果用戶端正從代理程式要求許多確認 (例如用戶端使用 CLIENT_ACKNOWLEDGE or AUTO_ACKNOWLEDGE 模式、永久性訊息、異動、佇列瀏覽器) 或用戶端正在新增或移除使用者時，imqConnectionFlowCount 的值應保持較低。相反地，如果用戶端只有使用 DUPS_OK_ACKNOWLEDGE 模式來連接簡易使用者時，那麼您可以增加 imqConnectionFlowCount 的值，而不需顧及效能。
訊息流量限制
JMS 訊息的數目有一個限制，即在遇到本地資源限制 (例如記憶體) 前，Message Queue 用戶端運行時間可處理的 JMS 訊息數目限制。到達此限制時，會對效能造成影響。因此，Message Queue 可限制每個使用者可在連接中發送，且在用戶端運行時間內進行緩衝的待使用訊息數目 (或每個連接的訊息數目)。
基於使用者的限制
如果任何使用者發送至用戶端運行時間的 JMS 訊息數超過 imqConsumerFlowLimit 的值時，則會停止發送訊息給該使用者。只有在發送給該使用者的未使用訊息數低於此 imqConsumerFlowThreshold 之設定值時，才恢復發送訊息。
以下範例說明這些限制的使用：考慮主題使用者的設定值
imqConsumerFlowLimit=1000
imqConsumerFlowThreshold=50
建立使用者時，代理程式會不間斷地發送包含 1,000 個訊息的初始批次 (假設訊息已存在) 給該使用者。傳送 1,000 個訊息後，代理程式會停止發送，直到用戶端運行時間要求發送其他訊息。應用程式處理這些訊息前，用戶端運行時間會保留這些訊息。接著，在要求代理程式傳送下一個批次前，用戶端運行時間會允許應用程式使用至少 50% (imqConsumerFlowThreshold) 的訊息緩衝容量 (例如 500 個訊息)。
在相同情況下，如果臨界值為 10% 時，在要求傳送下一個批次前，用戶端運行時間會等待應用程式至少使用 900 個訊息。
以下計算下一個批次的大小：
imqConsumerFlowLimit - (目前緩衝區中擱置的訊息數目)
如此一來，如果 imqConsumerFlowThreshold 為 50%，那麼下一個批次大小介於 500 到 1,000 之間，其實際數量取決於應用程式處理訊息的速度。
如果 imqConsumerFlowThreshold 設得太高 (接近 100%)，那麼代理程式會嘗試傳送較小的批次，以降低訊息流量。如果值過低 (接近 0%)，那麼用戶端可能可以在代理程式發送下一組批次前，完成處理其餘的緩衝訊息，這會造成訊息流量下降。一般來說，除非您有特殊效能或可靠性考量，否則您不需變更 imqConsumerFlowThreshold 屬性的預設值。
基於使用者的流量控制 (特別是 imqConsumerFlowLimit) 為管理用戶端運行時間中的最佳方法。通常，根據用戶端應用程式，您會曉得您在任何連接上需要支援的使用者數目、訊息大小和可用於用戶端運行時間的總記憶體容量。
基於連接的限制
然而，在一些用戶端應用程式中，使用者數目可能是不正確的，它取決於一般使用者的選擇。在此情況下，您仍可以使用連接級別流量限制來管理記憶體。
連接級別流量控制可限制用於連接上所有使用者的總緩衝訊息數目。如果此數目超過 imqConnectionFlowLimit，那麼在總數目降低到低於連接限制前，會停止透過連接的訊息發送。(只有在您將 imqConnectionFlowLimitEnabled 特性設為 true 時，才可啟用imqConnectionFlowLimit。)
階段作業中形成佇列的訊息數目為使用階段作業之使用者數目及用於每個使用者之訊息負載的函數。如果用戶端在產生和使用訊息中發生延遲，通常您可以藉由重新設定應用程式，以分散較大階段作業數目上的訊息產生者和使用者，或者分散較大連接數目上的階段作業，並因此改善效能。
