test

Sun Java System Message Queue 3.7 UR1 管理指南

第 12 章 排解疑難問題

本章說明如何瞭解及解決下列問題：

發生問題時，檢查所安裝 Message QueueTM 軟體的版本編號，通常很有幫助。版本編號可讓您確定所用文件的編號是否與軟體版本相符。向 Sun 報告問題時，也需要版本編號。若要檢查版本編號，請發出以下指令：

imqcmd -v

用戶端無法建立連線

徵兆：

可能原因：

可能原因：用戶端應用程式未關閉連線，導致連線數目超過資源限制。

若要確認此問題的原因：列出代理程式的所有連線：

imqcmd list cxn

輸出會列出所有連線和建立每個連線的主機，從而瞭解哪些用戶端開啟了過多的連線。

若要解決此問題：重新寫入違例用戶端，以關閉不使用的連線。

可能原因：未執行代理程式或網路連結發生問題。

若要確認此問題的原因：

若要解決此問題：

可能原因：連線服務不在使用中或已暫停。

若要確認此問題的原因：檢查所有連線服務的狀態：

imqcmd list svc

如果連線服務狀態顯示為 unknown 或 paused，則用戶端無法使用該服務建立連線。

若要解決此問題：

可能原因：可用於所需連線數目的可用執行緒太少。

若要確認此問題的原因：檢查代理程式記錄中的以下項目：

WARNING [B3004]: No threads are available to process a new connection on service ... Closing the new connection.

並且使用下列其中一種格式，檢查連線服務上的連線數目，以及目前使用中的執行緒數目：

imqcmd query svc -n serviceName imqcmd metrics svc -n serviceName -m cxn

每個連線均需要 2 個執行緒：一個用於內送訊息，另一個用於外寄訊息 (請參閱執行緒池管理)。

若要解決此問題：

可能原因：Solaris 或 Linux 平台上要求用於連線數目的檔案描述元太少。

如需有關此問題的更多資訊，請參閱設定檔案描述元限制。

若要確認此問題的原因：檢查代理程式記錄中是否有以下相似項目：

Too many open files

若要解決此問題：增加檔案描述元限制，如 ulimit 線上手冊所述。

可能原因：TCP 積存區會限制可同時新建連線請求的數目。

TCP 積存區會限制同時儲存在系統積存區內的連線請求數目 (imq.portmapper.backlog )，連接埠對映器會在超過此限制之後拒絕其他請求。(Windows 平台上有程序內定的積存區限制：Windows 個人版作業系統的數目限制為 5 個，Windows 伺服器版作業系統的數目為 200 個。)

因為不會經常出現同時有大量的連線請求，所以因儲存區限制的請求拒絕通常為短暫現象。

若要確認此問題的原因：檢查代理程式記錄。首先，檢查代理程式在拒絕其他連線的同時是否有接受某些連線。接著，檢查拒絕連線的說明訊息。如果找到這類訊息，可能不是 TCP 積存區的問題，因為代理程式不會記錄 TCP 積存區造成的拒絕連線。如果記錄中有成功的連線，但是未記錄任何拒絕連線，則可能是 TCP 積存區的問題。

若要解決此問題：

可能原因：作業系統限制同步運作中連線的數目。

Windows 作業系統授權會限制所支援的同步運作遠端連線的數目。

若要確認此問題的原因：檢查可用於連線的執行緒數目是否夠用 (使用 imqcmd query svc)，並檢查 Windows 授權合約的條款。如果您是從本地用戶端建立連線，而不是從遠端用戶端，作業系統限制可能是造成此問題的原因。

若要解決此問題：

可能原因：使用者的認證或授權失敗。

認證可能因為下列任一原因而失敗：

若要確認此問題的原因：檢查代理程式記錄中是否有 Forbidden 錯誤訊息的項目。這表示有驗證錯誤，但不表示為問題發生的原因。

若要解決此問題：

連線流量過慢

徵兆：

可能原因：

可能原因：網路連線或 WAN 太慢。

若要確認此問題的原因：

若要解決此問題：升級網路連結。

可能原因：連線服務協定的速度原本就比 TCP 的速度慢。

例如，SSL 型或 HTTP 型協定的速度會比 TCP 的速度慢 (請參閱傳輸協定)。

若要確認此問題的原因：如果您使用 SSL 型或 HTTP 型協定，請嘗試使用 TCP 並比較傳送時間。

若要解決此問題：通常，應用程式需求決定要使用的協定，所以除了如調校傳輸協定中所述嘗試調校協定效能外，沒有更多的辦法。

可能原因：連線服務協定未調校為最佳效能。

若要確認此問題的原因：嘗試調校協定，並查看是否有任何差異。

若要解決此問題：嘗試調校協定，如調校傳輸協定中所述。

可能原因：訊息過大導致使用過多的頻寬。

若要確認此問題的原因：嘗試以較小訊息執行效能評定。

若要解決此問題：

可能原因：實際上，連線流量過慢的問題，是訊息傳送程序的某些步驟中會遇到的瓶頸。

若要確認此問題的原因：如果上述原因都不是造成連線流量速度過慢的原因，則請參閱影響效能的因素，找出其他可能的瓶頸，並檢查是否有任何與以下問題相關的徵兆：

若要解決此問題：依照上述疑難排解各節提供的問題解決方案進行排解。

用戶端無法建立訊息產生器

徵兆：

可能原因：

可能原因：已將實體目標配置為僅允許有限數目的產生器。

為了防止在實體目標上累積訊息，方法之一就是限制實體目標可支援的產生器數目 (maxNumProducers)。

若要確認此問題的原因：檢查實體目標：

imqcmd query dst

(請參閱顯示實體目標資訊)。輸出會顯示目前的產生器數目和 maxNumProducers 的值。如果兩個值相同，表示產生器數目到達配置的限制。代理程式拒絕新的產生器時，該代理程式會傳回異常

ResourceAllocationException [C4088]: A JMS destination limit was reached

並且在代理程式記錄中產生以下項目：

[B4183]: Producer can not be added to destination

若要解決此問題：增加 maxNumProducers 屬性的值 (請參閱更新實體目標特性)。

可能原因：存取控制特性檔案中的設定未授權使用者建立訊息產生器。

若要確認此問題的原因：代理程式拒絕新的產生器時，代理程式會傳回異常

JMSSecurityException [C4076]: Client does not have permission to create producer on destination

並且在代理程式記錄中產生以下項目：

[B2041]: Producer on destination denied[B4051]: Forbidden guest.

若要解決此問題：變更存取控制特性，以允許使用者產生訊息 (請參閱實體目標的存取控制)。

訊息產生延遲或過慢

徵兆：

可能原因：

可能原因：訊息積存於代理程式上，因此回應訊息產生器的速度會變慢。

積存的代理程式會將訊息累積在代理程式記憶體中。實體目標記憶體中的訊息數目或訊息容量到達所配置的限制時，代理程式會依指定的限制運作方式，嘗試節省記憶體資源。以下限制運作方式會降低訊息產生器的速度：

同樣地，整個代理程式記憶體 (用於所有實體目標) 中的訊息數目或訊息容量到達所配置的限制時，代理程式會拒絕最新的訊息，以嘗試節省記憶體資源。再者，到達系統記憶體限制時，因為實體目標或整個代理程式的限制未正確設定，所以代理程式會採取愈來愈重要的動作，以防記憶體超載。這些動作包括減低訊息產生器的速度。

若要確認此問題的原因：當代理程式按照所配置的訊息限制來拒絕訊息時，代理程式會傳回異常

JMSException [C4036]: A server error occurred

並且在代理程式記錄中產生以下項目：

[B2011]: Storing of JMS message from IMQconn failed

此訊息後面還有一則訊息指出已經達到限制：

[B4120]: Cannot store message on destination destName because capacity of maxNumMsgs would be exceeded.

這是超出實體目標訊息限制時的狀況；或者

[B4024]: The maximum number of messages currrently in the system has been exceeded, rejecting message.

這是超出整個代理程式訊息限制時的狀況。

一般而言，您可以在遭到拒絕前，依以下方式檢查訊息限制條件：

若要解決此問題：

可能原因：代理程式無法將永久性訊息儲存到資料存放區。

如果代理程式無法存取資料存放區或將永久性訊息寫入資料存放區，則表示訊息產生用戶端被阻斷。這種情況亦會在目標或整個代理程式訊息到達限制時發生，如上所述。

若要確認此問題的原因：如果代理程式無法寫入資料存放區，則會在代理程式記錄中產生以下其中一個項目：

[B2011]: Storing of JMS message from connectionID failed [B4004]: Failed to persist message messageID

若要解決此問題：

可能原因：代理程式回應逾時過短。

由於連線速度慢或代理程式緩慢 (由於高 CPU 使用率或記憶體資源不足所引起)，代理程式可能需要更多時間確認永久性訊息的接收，所需要的時間會超過連線工廠 imqAckTimeout 屬性所允許的值。

若要確認此問題的原因：如果超過 imqAckTimeout 值，代理程式會傳回異常

JMSException [C4000]: Packet acknowledge failed

若要解決此問題：變更 imqAckTimeout 連線工廠屬性的值 (請參閱可靠性與流量控制)。

可能原因：訊息產生用戶端受到 JVM 限制。

若要確認此問題的原因：

若要解決此問題：調整 JVM (請參閱Java 虛擬機器調整)。

儲存訊息

徵兆：

若要查看是否累積訊息，請檢查代理程式中的訊息數目或訊息容量如何不斷變化，並與配置的限制進行比較。請先檢查配置的限制：

imqcmd query bkr

備註 –

imqcmd metrics bkr 子指令不會顯示此資訊。

接著檢查每個目標中的訊息累積：

imqcmd list dst

若要查看訊息是否超過所配置的目標或整個代理程式的限制，請檢查代理程式記錄中是否有以下項目：

[B2011]: Storing of JMS message from … failed.

此項目後面還有其他項目，說明已超過限制。

可能原因：

可能原因：主題目標上有非使用中的長期訂閱。

如果長期訂閱為非使用中，則訊息會儲存在目標中，直到對應的用戶變為使用中狀態並能使用這些訊息為止。

若要確認此問題的原因：檢查每個主題目標上的長期訂閱狀態：

imqcmd list dur -d destName

若要解決此問題：

可能原因：佇列中可使用訊息的用戶太少。

如果可接收所傳送訊息的使用中用戶太少，則訊息累積時可能會積存在佇列目標中。此情況會因以下任何一種原因而發生：

若要確認此問題的原因：請檢查目標上使用中用戶的數目，以便幫助您判斷用戶為何無法使用：

imqcmd metrics dst - n destName -t q -m con

若要解決此問題：根據無法使用用戶的原因：

可能原因：訊息用戶處理速度過慢，無法跟上訊息產生器的速度。

在此狀況下，主題訂閱者或佇列接收者使用訊息的速度，會比產生器傳送訊息的速度慢。因為此不平衡現象，所以一個或多個目標中會出現訊息積存。

若要確認此問題的原因：檢查傳入和傳出代理程式之訊息流量的速率：

imqcmd metrics bkr -m rts

然後檢查每個個別目標的流量速率：

imqcmd metrics bkr -t destType -n destName - m rts

若要解決此問題：

可能原因：用戶端確認處理會降低訊息使用速度。

有兩個因素會影響用戶端確認處理：

若要確認此問題的原因：

若要解決此問題：

可能原因：代理程式無法跟上產生訊息的速度。

在此狀況下，訊息傳入代理程式的速度，會比代理程式路由和派送訊息到用戶的速度快。代理程式運作遲緩可以是因為以下任何或所有限制造成：

若要確認此問題的原因：檢查是否有其他可能造成此問題的原因。

若要解決此問題：

可能原因：用戶端程式碼缺點；用戶不確認訊息。

在所有要接收所傳送之訊息的用戶確認訊息之前，這些訊息會被保留在目標中。如果用戶端不確認使用的訊息，那麼訊息會累積在目標中且不被刪除。

舉例來說，用戶端程式碼可能會有以下缺點：

若要確認此問題的原因：首先，檢查本節中列出的所有其他可能原因。然後，使用下列指令，列出目標：

imqcmd list dst

請注意 UnAcked 標頭下列出的訊息數目，是否與目標中的訊息數目相同。此標頭下的訊息已傳送到用戶，但是尚未經過確認。如果這個數目與訊息總數相同，表示代理程式已經送出所有訊息，正在等待確認。

若要解決此問題：請應用程式開發者協助除錯此問題。

代理程式的流量不穩定

徵兆：

可能原因：

可能原因：代理程式的記憶體資源非常少。

因為未正確設定目標與代理程式限制，代理程式會採取越來越嚴格的動作，以防記憶體超載，這會導致在清除積存的訊息前，代理程式運作緩慢。

若要確認此問題的原因：檢查記憶體不足狀況下的代理程式記錄

[B1089]: In low memory condition, broker is attempting to free up resources

後面還有一個項目，描述新的記憶體狀態和所使用的記憶體總數。也請檢查 JVM 堆疊中可用的記憶體：

imqcmd metrics bkr -m cxn

JVM 記憶體總數接近 JVM 記憶體最大值時，可用記憶體會不足。

若要解決此問題：

可能原因：正在執行 JVM 記憶體收回 (廢棄項目收集)。

記憶體收回程序會定期檢查整個系統，以釋放記憶體。發生此情況時，會阻斷所有執行緒。釋放出來的記憶體數量越多，JVM 堆疊的容量越大，因記憶體收回而導致的延遲時間就越長。

若要確認此問題的原因：監視電腦的 CPU 使用率。執行記憶體收回時，會大幅降低 CPU 使用率。

另外，請使用以下指令行選項以啟動代理程式：

- vmargs -verbose:gc

標準輸出會指出執行記憶體收回的時間。

若要解決此問題：在具有多個 CPU 的電腦中，設定同時執行記憶體收回：

-XX:+UseParallelGC=true

可能原因：JVM 使用及時 (Just-In-Time) 編譯器以提高效能。

若要確認此問題的原因：檢查是否有其他可能造成此問題的原因。

若要解決此問題：讓系統執行一段時間，效能應會改善。

訊息未送達用戶

徵兆：

可能原因：

可能原因：限制運作方式導致訊息在代理程式上被刪除。

目標記憶體中的訊息數目或訊息容量達到所配置的限制時，代理程式會嘗試節省記憶體資源。達到這些限制時，代理程式會採用 3 個可配置的運作方式，並因此導致訊息遺失：

若要確認此問題的原因：如停用的訊息佇列包含訊息中所描述，檢查停用的訊息佇列。尤其必須遵照「訊息數目或訊息容量超出目標限制」中的指示。尋找 REMOVE_OLDEST 或 REMOVE_LOW_PRIORITY 原因。

若要解決此問題：增加目標限制。例如：

imqcmd update dst -n MyDest - o maxNumMsgs=1000

可能原因：訊息的逾時值過期。

代理程式會刪除逾時值過期的訊息。如果目標積存了太多的訊息，則可能會刪除存在時間值過短的訊息。

若要確認此問題的原因：使用 QBrowser 示範應用程式，查看停用的訊息佇列內容及訊息是否逾時。如需 QBrowser 示範程式在特定平台上的位置，請參閱附錄 AMessage QueueTM 資料的特定平台位置，查看表格中的「應用程式範例與位置」。

以下是 Windows 平台上的呼叫範例：

cd \MessageQueue3\demo\applications\qbrowser java QBrowser

QBrowser 主視窗出現時，請選擇佇列名稱 mq.sys.dmq，然後按一下 [瀏覽]。會出現類似下面的清單：

QBrowser 顯示 mq.sys.dmq 的訊息。每個訊息都有編號、時間標記、類型、模式和優先權。

在任何訊息上連按兩下，即可顯示此訊息的詳細資訊。

訊息的詳細資訊視窗。上方窗格顯示訊息，中間窗格顯示訊息特性，下方窗格包含訊息。

請注意訊息 JMS_SUN_DMQ_UNDELIVERED_REASON 特性的值是否為 EXPIRED。

若要解決此問題：連絡應用程式開發者並增加使用期限值。

可能原因：時鐘不同步。

如果時鐘不同步，代理程式計算訊息的使用期限會發生錯誤，如此會導致訊息逾時並被刪除。

若要確認此問題的原因：查看代理程式記錄檔中有無下列訊息：B2102、B2103、B2104。這些訊息都報告偵測到時鐘可能不準。

若要解決此問題：如準備系統資源中所述，檢查有無執行時間同步化程式。

可能原因：訊息使用用戶端無法啟動連線上的訊息傳送。

在用戶端程式碼建立連線並啟動該連線上的訊息傳送之前，將無法傳送訊息。

若要確認此問題的原因：檢查用戶端程式碼是否建立連線並啟動訊息傳送。

若要解決此問題：重新寫入用戶端程式碼，以建立連線並啟動訊息傳送。

停用的訊息佇列包含訊息

徵兆： 


Listing all the destinations on the broker specified by:
---------------------------------
Host         Primary Port
---------------------------------
localhost    7676
----------------------------------------------------------------------
   Name     Type    State   Producers  Consumers  Msgs
                                         Total    Count  UnAck  Avg Size
------------------------------------------------- ----------------------
MyDest      Queue  RUNNING       0          0        5      0    1177.0
mq.sys.dmq  Queue  RUNNING       0          0       35      0    1422.0
Successfully listed destinations.

在此範例中，停用的訊息佇列 mq.sys.dmq 包含 35 個訊息。

可能原因：

可能原因：訊息數目或訊息容量超出目標限制。

若要確認此問題的原因：使用 QBrowser 示範應用程式，查看停用的訊息佇列內容。如需 QBrowser 示範程式在特定作業系統上的位置，請參閱附錄 AMessage QueueTM 資料的特定平台位置，查看表格中的「應用程式範例與位置」。

以下是 Windows 平台的呼叫範例：

cd \MessageQueue3\demo\applications\qbrowser java QBrowser

QBrowser 主視窗出現時，請選擇佇列名稱 mq.sys.dmq，然後按一下 [瀏覽]。出現的清單與先前在「訊息的逾時值過期」下顯示的清單類似。連按兩下任何訊息，以顯示此訊息的詳細資訊，如「訊息的逾時值過期」下所示。

請注意下列訊息特性值：

請注意 JMS Headers 下的 JMSDestination 值，以便判斷將要停用其訊息的目標。

若要解決此問題：增加目標限制。例如：

imqcmd update dst - n MyDest -o maxNumMsgs=1000

可能原因：代理程式時鐘和產生器時鐘不同步。

若要確認此問題的原因：使用 QBrowser 應用程式，檢視停用的訊息佇列中訊息的詳細資訊。檢查 JMS_SUN_DMQ_UNDELIVERED_REASON 的值，尋找原因為 EXPIRED 的訊息。

查看代理程式記錄檔中有無下列訊息：B2102、 B2103、B2104。這些訊息都報告偵測到時鐘可能不準。

若要解決此問題：如準備系統資源中所述，檢查有無執行時間同步化程式。

可能原因：用戶在訊息逾時前一直未收到訊息。

若要驗證此問題的原因：使用 QBrowser 應用程式，檢視停用的訊息佇列中訊息的詳細資訊。檢查 JMS_SUN_DMQ_UNDELIVERED_REASON 的值，尋找原因為 EXPIRED 的訊息。

檢查目標上有無任何用戶。例如：

imqcmd query dst -t q -n MyDest

檢查列出的 Current Number of Active Consumers 值。如果有使用中的用戶，下列其中一項為 true：

若要解決此問題：請應用程式開發者增加訊息存在時間值。

可能原因：產生器數目對於用戶數目而言過多。

若要確認此問題的原因：使用 QBrowser 應用程式，檢視停用的訊息佇列中訊息的詳細資訊。檢查 JMS_SUN_DMQ_UNDELIVERED_REASON 的值。如果原因是 REMOVE_OLDEST 或 REMOVE_LOW_PRIORITY ，請使用 imqcmd query dst 指令，檢查目標上的產生器數目和用戶數目。如果產生器數目超過用戶數目，產生速率可能高於使用速率。

若要解決此問題：使用如下所示的指令，增加更多的訊息使用用戶端，或將目標的限制運作方式設定為 FLOW_CONTROL (以使用速率控制產生速率)：

imqcmd update dst -n myDst -t q -o consumerFlowLimit=FLOW_CONTROL

可能原因：產生器的速度比用戶快。

若要確認此問題的原因：若要判斷是否因為用戶速度慢而導致產生器的速度變慢，請使用如下所示的指令，將目標的限制運作方式設定為 F LOW_CONTROL (以使用速率控制產生速率)：

imqcmd update dst -n myDst -t q -o consumerFlowLimit=FLOW_CONTROL

利用如下所示的指令，使用度量來檢查目標的輸入與輸出：

imqcmd metrics dst - n myDst -t q -m rts

在度量輸出中，檢查下列的值：

流量控制會針對使用調整產生，注意產生速度是否變慢或停止。如果產生速度變慢或停止，則表示產生器和用戶的處理速度有差異。您也可以使用 imqcmd list dst 指令，檢查已傳送的未確認 (UnAcked) 訊息數目。如果未確認的訊息數目小於目標容量，表示目標有其他容量受到用戶端的流量控制所控制。

若要解決此問題：如果產生速率一直快於使用速率，請考慮定期使用流量控制讓系統步調一致。後續幾節介紹如何解決下面的可能因素：

可能原因：用戶的速度太慢。

若要確認此問題的原因：如「產生器的速度比用戶快」中所描述，使用度量來判斷產生速率和使用速率。

若要解決此問題：

可能原因：用戶端未確定訊息。

若要確認此問題的原因：向應用程式開發者查詢應用程式是否使用作業事件。如果應用程式使用作業事件，請列出使用中作業事件，如下所示：

imqcmd list txn

下列是指令輸出的範例：


----------------------------------------------------------------------
Transaction ID       State    User name  # Msgs/# Acks   Creation time
----------------------------------------------------------------------
6800151593984248832  STARTED  guest           3/2     7/19/04 11:03:08 AM

請注意訊息和確認的數目。如果訊息數目大於確認數目，表示產生器可能有傳送個別訊息，但卻無法確定作業事件。代理程式收到確定後，才能路由並傳送該項作業事件的訊息。如果確認數目大於訊息數目，表示用戶可能有傳送個別訊息，但卻無法確定作業事件。代理程式收到確定後，才能移除該項作業事件的確認。

若要解決此問題：請連絡應用程式開發者，修正程式錯誤。

可能原因：用戶無法確認訊息。

若要確認此問題的原因：連絡應用程式開發者，判斷應用程式使用系統型確認或用戶端型確認。如果應用程式使用系統型確認，請略過本節。如果應用程式使用用戶端型確認 (CLIENT_ACKNOWLEDGE)，請使用如下所示的指令，先減少用戶端上儲存的訊息數目：

imqcmd update dst -n myDst -t q -o consumerFlowLimit=1

然後判斷是因為用戶的速度太慢而使代理程式緩衝訊息，或是用戶處理訊息的速度很快，只是未確認訊息。使用下列指令，列出目標：

imqcmd list dst

提供使用者名稱和密碼之後，出現類似下列的輸出：


Listing all the destinations on the broker specified by:
---------------------------------
Host         Primary Port
---------------------------------
localhost    7676
----------------------------------------------------------------------
   Name     Type    State   Producers  Consumers  Msgs
                                         Total    Count  UnAck  Avg Size
------------------------------------------------ -----------------------
MyDest      Queue  RUNNING       0          0        5    200    1177.0
mq.sys.dmq  Queue  RUNNING       0          0       35      0    1422.0
Successfully listed destinations.

UnAck 數目代表代理程式傳送出去後等待確認的訊息數目。如果此數目變大或增加，表示代理程式正在傳送訊息，不等待速度較慢的用戶。您也可以看出用戶未確認訊息。

若要解決此問題：請連絡應用程式開發者，修正編碼錯誤。

可能原因：長期用戶處於非使用中狀態。

若要確認此問題的原因：使用下列的指令格式，查看主題的長期訂閱者：

imqcmd list dur -d topicName

若要解決此問題：

可能原因：發生非預期的代理程式錯誤。

若要確認此問題的原因：如「產生器的速度比用戶快」中所描述，使用 QBrowser 檢查訊息。如果 JMS_SUN_DMQ_UNDELIVERED_REASON 的值是 ERROR ，表示代理程式發生錯誤。

若要解決此問題：