Sun Java System Message Queue 3.7 UR1 管理指南

系統調校

以下各小節描述您可對作業系統、JVM 和通訊協定所做的調整。

Solaris 調校:CPU 使用、分頁/交換/磁碟 I/O

請參閱您系統的文件來調校您的作業系統。

Java 虛擬機器調整

依預設,代理程式會使用 192MB 的 JVM 堆疊容量。此容量對大量的訊息負載通常過小,所以應增加其大小。

當代理程式將要耗盡 Java 物件使用的 JVM 堆疊儲存區空間時,會使用各種技術 (如流量控制和訊息交換) 來釋放記憶體。在極端情況下,它甚至會關閉用戶端連線以釋放記憶體,並降低訊息的傳入量。因此,最好將最大 JVM 堆疊儲存區空間設定得足夠大,以避免發生此類情況。

但是,如果將最大 Java 堆疊儲存區空間設定得過大 (相對於系統實體記憶體),代理程式會持續增加 Java 堆疊儲存區空間,直至整個系統的記憶體用完。這會導致效能降低、不可預料的代理程式當機,和/或影響系統上執行的其他應用程式和服務的運作。一般而言,您需要允許足夠用於作業系統和機器上其他執行應用程式的實體記憶體。

一般而言,最好先評估正常時段和尖峰時段的系統記憶體使用量,然後再配置 Java 堆疊容量,該容量大小應足以提供良好的效能,但又不至於大到導致系統記憶體問題。

若要變更代理程式的最小和最大堆疊容量,請在啟動代理程式時,使用 -vmargs 指令行選項。例如:

/usr/bin/imqbrokerd -vmargs "-Xms256m -Xmx1024m"

此指令會將 Java 堆疊容量的下限設定為 256MB,上限為 1GB。

在任何狀況下,都請檢查代理程式的記錄檔或使用 imqcmd metrics bkr -m cxn 指令,以驗證設定。

調校傳輸協定

選擇符合應用程式需求的協定後,可進行額外調校 (以選取的協定為基礎) 以改善效能。

以下 3 個代理程式特性可用來修改協定效能:

對於 TCP 和 SSL 協定,這些特性會影響用戶端和代理程式之間訊息傳送的速度。對於 HTTP 和 HTTPS 協定,這些特性會影響 Message Queue 通道 Servlet (在 Web 伺服器上執行) 和代理程式之間訊息傳送的速度。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 會設定輸出串流上的緩衝區大小,輸出串流由代理程式用來將資料寫入通訊端。

一般而言,兩個參數值皆應稍微大於接收或傳送的平均封包容量。根據經驗,請將這些特性值設定為比平均資料封包容量多 1 KB (四捨五入至最接近的以 KB 為單位之整數值)。例如,如果代理程式接收內文容量為 1 KB 的資料封包,則該封包 (訊息內文加上標頭和特性) 的總容量約為 1.2 KB;inbufsz 為 2 KB (2048 個位元組) 即可提供適當的效能。將 inbufsz outbufsz 增加到超過此容量可能會稍微改善效能,但是將增加各個連線所需的記憶體。

HTTP/HTTPS 調校

除了前面兩小節描述的一般特性之外,HTTP/HTTPS 效能受限於用戶端發出 HTTP 請求到託管 Message Queue 通道 Servlet 之 Web 伺服器的速度。

Web 伺服器可能需要最佳化,以處理單一通訊端上的多個請求。從 JDK 1.4 版或更新版本開始,HTTP 與 Web 伺服器的連線會持續作用 (到 Web 伺服器的通訊端會保持開啟),以便在 Web 伺服器處理多個 HTTP 請求時,將 Web 伺服器使用的資源降到最低。在相同用戶端應用程式上使用 JDK 1.4 版的效能,如果比使用較早 JDK 版本的效能低,則您可能需要調校 Web 伺服器持續作用的配置參數,以改善效能。

除了對 Web 伺服器進行此類調校,您也可以調整用戶端輪詢 Web 伺服器的頻率。HTTP 是請求型協定。這表示,使用 HTTP 型協定的用戶端會定期檢查 Web 伺服器,以查看是否有等待中的訊息。imq.httpjms.http.pullPeriod 代理程式特性 (以及類似的 imq.httpsjms.https.pullPeriod 特性) 會指定 Message Queue 用戶端執行階段輪詢 Web 伺服器的頻率。

如果 pullPeriod 值為 -1 (預設值),則用戶端執行階段會在前一個請求傳回時立即輪詢伺服器,以便最有效發揮個別用戶端的效能。因此,各個用戶端連線均會獨占 Web 伺服器中的一個請求執行緒,因而可能會過度使用 Web 伺服器資源。

如果pullPeriod 值為正數,則用戶端執行階段會定期傳送請求到 Web 伺服器,以查看是否有擱置的資料。在此狀況下,用戶端不會獨占 Web 伺服器中的請求執行緒。因此,如果大量用戶端使用 Web 伺服器,則您可能需要將 pullPeriod 設定為正值,以節省 Web 伺服器資源。

調校檔案式永久性存放區

如需有關調校檔案式永久性存放區的資訊,請參閱永久性服務