WebSphere Process Server V6.2 性能調優,第 3 部分 消息引擎性能調優2

 

 

 

[3/9/09 18:07:54:327 CST] 00000086 SibMessage I [SCA.SYSTEM.widCell.Bus:default.AppTa

rget.000-SCA.SYSTEM.widCell.Bus] CWSIS1538I:

The messaging engine, ME_UUID=2025B17928C161D

6, INC_UUID=303A303AEAB3EDD7, is attempting to obtain an exclusive lock on the data

store.

[3/9/09 18:07:59:343 CST] 00000086 SibMessage I [SCA.SYSTEM.widCell.Bus:default.AppTa

rget.000-SCA.SYSTEM.widCell.Bus] CWSIS1546I:

The messaging engine, ME_UUID=2025B17928C161D

6, INC_UUID=303A303AEAB3EDD7, has lost an existing lock or failed to gain an initial

lock on the data store.

[3/9/09 18:08:04:227 CST] 00000086 SibMessage I [SCA.APPLICATION.widCell.Bus:default.

AppTarget.000-SCA.APPLICATION.widCell.Bus] CWSIS1538I:

The messaging engine, ME_UUID=F1FF9

3EDD8DCD63B, INC_UUID=7CF47CF484B974F5, is attempting to obtain an exclusive lock on

the data store.

[3/9/09 18:08:09:329 CST] 00000086 SibMessage I [SCA.APPLICATION.widCell.Bus:default.

AppTarget.000-SCA.APPLICATION.widCell.Bus] CWSIS1546I:

The messaging engine, ME_UUID=F1FF9

3EDD8DCD63B, INC_UUID=7CF47CF484B974F5, has lost an existing lock or failed to gain an

initial lock on the data store.

[3/9/09 18:08:11:237 CST] 00000086 SibMessage I [CommonEventInfrastructure_Bus:defaul

t.AppTarget.000-CommonEventInfrastructure_Bus] CWSIS1538I:

The messaging engine, ME_UUID=D

65CBBE3A63BDFD6, INC_UUID=6FAA6FAA85818EDB, is attempting to obtain an exclusive lock

on the data store.

[3/9/09 18:08:14:465 CST] 00000086 SibMessage I [CommonEventInfrastructure_Bus:defaul

t.AppTarget.000-CommonEventInfrastructure_Bus] CWSIS1546I:

The messaging engine, ME_UUID=D

65CBBE3A63BDFD6, INC_UUID=6FAA6FAA85818EDB, has lost an existing lock or failed to

gain an initial lock on the data store.

[3/9/09 18:08:18:398 CST] 00000086 SibMessage I [BPC.widCell.Bus:default.AppTarget.00

0-BPC.widCell.Bus] CWSIS1538I:

The messaging engine, ME_UUID=B5290700DB25A3BE, INC_UUID=14

96149685818EF1, is attempting to obtain an exclusive lock on the data store.

[3/9/09 18:08:19:144 CST] 00000086 SibMessage I [BPC.widCell.Bus:default.AppTarget.00

0-BPC.widCell.Bus] CWSIS1546I:

The messaging engine, ME_UUID=B5290700DB25A3BE, INC_UUID=14

96149685818EF1, has lost an existing lock or failed to gain an initial lock on the

data store.

 

 

 

對於消息引擎的調優,必須把握一個原則:其他服務器消息引擎嘗試連接數據庫的時間大於數據庫探測以前的連接丟失的時間

WPS 會在一定時間內等待數據庫連接恢復。缺省狀況下,其他服務器上消息引擎會在 15 分鐘內以 2 秒的頻率嘗試連接數據庫,如果仍無法連接則放棄重連;而數據庫所在的操作系統通過 keepalive 等參數來探測數據庫與消息引擎的連接是否丟失。對於常用操作系統如 Windows,AIX 等,這個參數的缺省值是 2 個小時。可見,如果使用缺省值,數據庫機器會在連接丟失後 2 小時內保持互斥鎖,而可用的其它消息引擎只會嘗試 15 分鐘重連,造成無法實現故障轉移的現象。因此,您可以從以下兩個方面分別對 WPS 和數據庫所在機器進行調優,實現消息引擎的故障轉移:

1. 配置數據庫所在機器

操作系統控制 TCP/IP 連接的參數如表 2 所示:

表 2. 在 Windows 和 AIX 系統上相關參數及描述

在 Windows 系統上參數名

在 AIX 系統上參數名

參數描述

KeepAliveTime

tcp_keepidle

對於不活動的連接方發送 keepalive 請求的間隔

KeepAliveInterval

tcp_keepintvl

等待請求回復的間隔

TCPMaxDataRetransmissions

tcp_keepcnt

重複發送請求的次數

操作系統獲知連接丟失的時間 = keep alive time + (keep alive interval x 請求次數)。我們要保證的是調優後操作系統獲知連接丟失的時間小於消息引擎嘗試連接時間,此時即可實現正確的故障轉移。

由於操作系統不同,修改 keepalive 參數的方法也不同,請您參照使用的操作系統手冊進行相應的修改,在此便不一一贅述了。

2. 配置 WPS

1) 在管理控制台里點擊服務集成 (Service integration) -> 總線 (Buses) -> 總線名稱 -> 消息引擎 -> 引擎名 -> 【其他屬性】定製屬性

2) 新建定製屬性並起名為 sib.msgstore.jdbcInitialDatasourceWaitTimeout ,此屬性控制等待重連數據庫的時間。並輸入屬性值,單位為毫秒。缺省值為 900000(15 分鐘)。點擊”確定” 。保證調優後此數值大於數據庫探測連接丟失的時間即可,本例中設為 1800000(30 分鐘),如圖 5 所示:

圖 5. 新建消息引擎定製屬性

3) 另新建定製屬性 sib.msgstore.jdbcStaleConnectionRetryDelay ,本屬性控制每次重連數據庫的時間間隔。輸入屬性值,單位為毫秒,缺省為 2000(2 秒),本例中設為 5000(5 秒),如圖 6 所示。點擊”確定”。

圖 6. 新建消息引擎定製屬性

4) 將修改保存到主配置。

5) 在集群環境中,我們需要對其中的每一個消息引擎都重複上述步驟,並重啟服務器使修改生效。

回頁首

將消息引擎數據存儲器遷移到更高性能的數據庫

由於消息引擎需要頻繁與後台的存儲器進行交互,儲存或讀取消息數據,因此存儲器的性能在很大程度上影響了消息引擎的性能。 我們在創建 WPS 或 WESB 概要文件時,缺省使用的是 Derby 數據庫。 Derby 數據庫可以滿足一般測試、開發的需要,但是在高吞吐量的生產環境中不適合使用;同樣的,我們也不建議您在生產系統中使用文件系統作為消息引擎的數據存儲器。

為了達到更好的性能我們建議您使用符合生產環境需求的數據庫,比如 DB2 等企業級數據庫。它們提供的性能和技術可以讓消息引擎的性能達到最佳,並可以儘可能避免消息數據庫給整個應用系統帶來的性能瓶頸。您可以在創建概要文件的時候就選擇創建高級概要文件的選項來選擇使用 DB2 數據庫。但是如果您的 WPS 概要文件已經創建,而它使用的數據存儲器無法達到系統性能要求時,您可以不用重新創建一個新的概要文件,而是參考如下的示例和步驟,將現有的概要文件所使用的數據存儲器遷移至 DB2。由於步驟比較繁瑣,下面的內容將十分詳細的介紹整個遷移過程,其中包括:數據庫的創建,JDBC 驅動的選擇和創建,數據源遷移等內容。

在我們開始遷移之前,需要了解源數據存儲器狀況,並考慮如何規劃目標數據庫。當您創建完概要文件並配置好業務流程編排器 (Business Process Choreographer) 後,我們應該有四條消息總線,每條消息總線里都有一個消息引擎。表 3 就展示了在單元名稱為 widCell 的單元上的四條消息總線:

表 3. 在 widCell 單元上的總線和消息引擎

總線名

消息傳遞引擎名

SCA.SYSTEM.widCell.Bus

widNode.server1-SCA.SYSTEM.widCell.Bus

SCA.APPLICATION.widCell.Bus

widNode.server1-SCA.APPLICATION.widCell.Bus

CommonEventInfrastructure_Bus

widNode.server1-CommonEventInfrastructure_Bus

BPC.widCell.Bus

widNode.server1-BPC.widCell.Bus

每一個數據存儲器都保存在各自的數據庫里,也就是說缺省一共有四個數據庫需要遷移。這意味着,如果遷移數據庫的話, DB2 也要相應的新建四個數據庫。對於 DB2 管理員來說這並不是一個很好的選擇,因為可能您的數據庫系統中已經有很多的數據庫存在了,而再增加四個數據庫會增添維護和優化的負擔。因此我們建議您可以使用單一的一個 DB2 數據庫來保存這四個數據存儲器,因為這四個存儲器彼此是完全隔絕的,並且每一個消息引擎都在啟動時會獲取自己對應的表的互斥鎖,保證消息數據的一致性。此外,每一個消息引擎可以使用唯一的一個模式名來區分自己的表,因此將四個存儲器保存在同一個數據庫中並不會影響數據的一致性或者造成混亂。

下面就是將已有的消息引擎數據存儲器遷移至 DB2 的步驟:

1. 創建 DB2 的數據庫並導入數據存儲器的模式

與一條消息引擎對應一個 DB2 數據庫相反,我們將所有的消息引擎都放在同一個數據庫中,只是用不同的模式來區分,如表 4 所示:

表 4. 消息引擎與模式名

模式名

消息傳遞引擎名

SCASYS

widNode.server1-SCA.SYSTEM.widCell.Bus

SCAAPP

widNode.server1-SCA.APPLICATION.widCell.Bus

CEIMSG

widNode.server1-CommonEventInfrastructure_Bus

BPCMSG

widNode.server1-BPC.widCell.Bus

您可以使用如下腳本在 Windows 系統里為每一個消息引擎創建一個模式定義。在示例中,我們將用 <WPS Install> 代表 WPS 安裝路徑, <user> 表示用戶名。下面的例子展示了如何在 Windows 系統中產生適用於 DB2 8.1 版本,用於創建名為 BPCMSG 的模式定義腳本:

<WPS Install>\bin\sibDDLGenerator.bat -system db2 -version 8.1 -platform windows -statementend ; -schema BPCMSG -user <user> >createSIBSchema_BPCMSG.ddl

對每一條消息引擎都重複運行上述腳本。

注意:如果目標數據庫版本高於 Oracle 11g, DB2 9.1 or Informix 11.0, 運行以上的腳本會有問題,這個問題通過 PK76196 進行了修正。

您可以根據您的數據庫環境編輯和修改模式定義文件,此後便可以在 DB2 數據庫中創建一個數據庫,例如 “SIB” ,並創建相應的表空間。然後,載入上述生成的四個模式定義文件來創建 SIB 數據庫里的模式和表。

通過這一系列步驟,我們在 DB2 中創建了新的表,表空間,模式以及一個新的數據庫作為遷移的目標。

2. 創建消息引擎的數據存儲器

接下來我們需要在管理控制台中為每個消息引擎創建一個數據源,並將它們指向新的數據儲存器。

數據源依賴於 JDBC 提供程序,因此我們需要確定 WPS 系統中已經配置有 DB2 JDBC 提供程序。而 JDBC 提供程序又分為 XA 和非 XA 兩種類型的。它們的區別在於, XA 類型的 JDBC 提供程序使用的是兩階段提交 (two phase commit) 協議,而非 XA 類型的 JDBC 提供程序則是單階段提交 (one phase commit)。在 WPS 中,對於 CEI 的數據源我們應該使用 XA 類型的 JDBC 提供程序;其餘的使用非 XA 類型的即可,如表 5 所示:

表 5. 消息引擎數據源名、 JNDI 名和使用的 JDBC 提供程序類型

數據源名稱

JNDI 名

JDBC 提供程序類型

CEIMSG_sib

jdbc/sib/CEIMSG

DB2 Universal (XA)

SCAAPP_sib

jdbc/sib/SCAAPPLICATION

DB2 Universal

SCASYSTEM_sib

jdbc/sib/SCASYSTEM

DB2 Universal

BPCMSG_sib

jdbc/sib/CEIMSG

DB2 Universal

如果在您的環境里沒有叫做 “DB2 通用 JDBC 提供程序”的 XA 類型以及非 XA 類型的 JDBC 提供程序,您可以手工創建。下面的例子展示了如何在系統中創建一個 XA 類型的 JDBC 提供程序:

在管理控制台 -> 資源 -> JDBC -> JDBC 提供程序,點擊”新建 “,出現如圖 7 所示的嚮導界面:

圖 7. 創建新的 XA 類型的 JDBC 提供程序步驟 1

以下文章點擊率最高

Loading…

     

如果這文章對你有幫助,請掃左上角微信支付-支付寶,給於打賞,以助博客運營