IBM WebSphere Portal Web Content Manager 和 DB2 調優指南

正在尋找一個資源中心來調優 WebSphere® Portal Web Content Management 和 IBM® DB2® for Linux®, UNIX®, and Windows® 環境？本文描述該環境獨特的、需要特殊考慮的各個部分。您將學習如何調優 Application Server 和 WebSphere Portal。作為良好的開端，您將學習一些應該設定為指定值的各種登錄檔變數和資料庫管理器及資料庫配置引數。最後，持續維護小節提供瞭如何使 DB2 系統隨系統增長仍然高效執行的指導原則。

對環境進行效能調優

WebSphere Portal 環境的調優涉及到對該環境的不同的系統和元件的調優和配置。本節討論一些通用的概念，並詳細描述本文評測環境所使用的配置的特徵。 WebSphere Portal Web Content Management (WCM) AIX® Power4 評測環境的配置和調優是基於 WebSphere Portal AIX Power4 環境的，IBM WebSphere Portal Version 6.0 Tuning Guide 對後者作了詳細闡述。用於評測 WCM 的環境的所有不同之處在本章中都會明確提出。對任何 WebSphere Portal 環境的完整的調優和配置方法包括：

• 配置應用伺服器和為這個應用伺服器定義的資源
• 確定用於擴充套件環境的複製策略
• 調優資料庫和資料庫伺服器
• 調優目錄伺服器和它的資料庫
• 調優 web 伺服器
• 調優作業系統和網路
• 調優 WebSphere Portal 服務

在調優各個系統時，首先應該具備一個基準，並監視效能指標，以確定是否應該更改某個引數，當作出更改時，也要監視效能指標，以確定更改的效果。

瞭解環境

WebSphere Portal V6.0 使用附加的伺服器來提供其功能。在我的評測環境中，除了 portal 伺服器本身以外，還有一個 Web 伺服器，一個資料庫伺服器和一個目錄伺服器，這些伺服器放在 WebSphere Portal 系統之外的單獨的系統上。採用這種配置的主要好處是可以避免同一個系統上的多個伺服器之間爭用資源。如果其他伺服器與 WebSphere Portal 伺服器爭用資源，就會影響系統可達到的吞吐率。在本報告中，用於評測的配置將 IBM HTTP Server 與 WebSphere Portal 放在同一個系統上。

應用伺服器調優

在 WebSphere Application Server 中，應用伺服器的配置和調優有很多方面。我發現，本文和 IBM WebSphere Portal Version 6.0 Tuning Guide 中描述的那些方面對於 WebSphere Portal 在我們的實驗環境中正確、高效地執行非常關鍵。要了解關於調優 WebSphere Application Server 的更多細節，請參閱資訊中心的 調優小節。

根據我對於本文描述的工作負載的經驗，表 1 展示了與用於 Power4 平臺的 AIX 的 IBM WebSphere Portal Version 6.0 Tuning Guide 不同的一些配置：

JVM 最大堆大小限制

在為應用伺服器設定堆大小時，要記住：確保系統有足夠的物理空間，以便將所有程式裝入實體記憶體，並滿足作業系統需要。如果分配的記憶體大於系統的實體記憶體，就會發生分頁，從而導致糟糕的效能。

我將堆大小的最小值和最大值設定為相同的值，對於在 IBM JDK 上執行的生產系統來說，這可能不是最佳選擇。在我的評測中，系統承受負載的時間很短（大約 3 小時），並且執行的 portlet 的記憶體需求不大。如果使用記憶體需求較大的 portlet，或者要持續執行，那麼通過將初始堆大小設定為 320 MB 可能會減少堆碎片。

對堆大小進行調優之後，要監視系統，以確保沒有發生分頁。如前所述，換頁會導致糟糕的效能。

如何設定引數：

在 WebSphere Administrative Console 中，選擇 Servers -> Application Servers -> WebSphere Portal -> Server Infrastructure: Java and Process Management -> Process Definition -> Java Virtual Machine
可以在下面兩個地方更改堆大小：
- Initial Heap Size
- Maximum Heap Size

JVM 堆大記憶體頁

該設定可以與 IBM JVM 一起使用，以使用大記憶體頁分配堆空間。為支援大記憶體頁，AIX 作業系統必須進行配置。使用大記憶體頁可以減少跟蹤堆所需的 CPU 開銷。通過這樣的調優，我的評測吞吐率提高了 10%。

如何設定引數：

1. 在 WebSphere Administrative Console 中，選擇 Servers -> Application Servers -> WebSphere Portal -> Server Infrastructure: Java and Process Management -> Process Definition -> Java Virtual Machine -> Generic JVM Argument
   新增： -Xlp
2. 在 WebSphere Administrative Console 中，選擇 Servers -> Application Servers -> WebSphere Portal -> Server Infrastructure: Java and Process Management -> Process Definition -> Custom Properties -> New -> EXTSHM=OFF
   （注意：當 EXTSHM 開啟時，會阻止大記憶體頁的使用。）
3. 停止 Portal 伺服器
4. 配置 AIX，以支援大記憶體頁。我使用以下步驟分配 1856 MB 的 RAM 作為大記憶體頁（16MB）。之所以選擇這個大小，是因為這些系統中有 4GB 的實體記憶體。對於採用不同實體記憶體大小的系統，這些值應有所調整。
   vmo -r -o lgpg_regions=116 -o lgpg_size=16777216
   bosboot -a
   reboot -q
   vmo -p -o v_pinshm=1
   chuser capabilities=CAP_BYPASS_RAC_VMM,CAP_PROPAGATE $USER
5. 重新啟動 Portal Server。要確認是否正在使用大記憶體頁，執行 AIX 命令 vmstat -l 1 5 並檢視 “alp” 列，它是當前使用的活動大記憶體頁。如果正在使用大記憶體頁，那麼它應該是一個非 0 值。

kCluster 和 pCluster

JVM 堆上的物件通常是移動的；也就是說，Garbage Collector（GC）在決定重排列堆時，可能會移動這些物件。但是，無論是永久地還是暫時地，有些物件是不能移動的。那些不能移動的物件被稱作固化物件（pinned object）。

在版本 1.3.1 Service Refresh 7 及之前版本中，GC 首先在堆的底部分配一個 kCluster 作為第一個物件。kCluster 是一個儲存區域，專門用於類塊。它大到足以容納 1280 個條目。每個類塊長度為 256 位元組。

然後，GC 分配一個 pCluster 作為堆上的第二個物件。pCluster 是用於分配固化物件的儲存區域。它的長度為 16 KB。

當 kCluster 耗盡時，GC 將類塊分配在 pCluster 中。當 pCluster 也耗盡時，GC 分配一個 2 KB 的新的 pCluster。

由於這個新的 pCluster 可以分配在堆中的任何位置，並且必須是固定的，因此可能導致碎片問題。固化物件使 GC 不能在堆壓縮期間合併空閒空間，因而可能導致一個堆有很多容量較小的空閒空間，所以即使某次分配明顯少於空閒空間總量，也不能成功分配。為解決這個問題，1.3.1 和更高版本的 SR7 提供了一些命令列選項，用於指定 kCluster（-Xk）、pCluster（-Xp）和 pCluster 的溢位大小（-Xp）。使用這些選項將簇的初始大小設定得足夠大，以避免碎片問題。

如何設定引數：

在 WebSphere Administrative Console 中，選擇 Servers -> Application Servers -> WebSphere Portal -> Server Infrastructure: Java and Process Management -> Process Definition -> Java Virtual Machine -> Generic JVM Argument
輸入 -Xk30000 -Xp24000k,2400k

資料來源調優

根據 WebSphere Portal 資訊中心的描述，WebSphere Portal V6.0 使用多個資料庫。在我的例子中，我使用 7 個獨立的資料庫，每個資料庫都有它自己的資料來源。這些資料來源是：

對於預置語句快取大小，路徑為 Resources -> JDBC Providers -> provider name -> Data Sources -> datasource name -> WebSphere Application Server data source properties。provider name 和 datasource name 隨資料庫遷移期間為資料庫選定的名稱而定。檢視引數 statement cache size。

我們將所有資料來源的預置語句快取大小設為 1 條語句，以減少對本地記憶體的需求，從而避免系統崩潰。

回頁首

DB2 登錄檔變數

下面的登錄檔變數應該在例項級設定（使用 db2set 命令）：

以例項使用者身份，輸入以下命令，以設定 DB2 登錄檔變數：

db2set DB2_RR_TO_RS=YES
db2set DB2_EVALUNCOMMITTED=YES
db2set DB2_SKIPDELETED=ON
db2set DB2_INLIST_TO_NLJN=YES
db2set DB2_MINIMIZE_LISTPREFETCH=ON

可選變數

如果 DB2 所在系統是 CPU 密集型，那麼還可以設定下面的引數。由於這個變數對於所有包含多於 5 個連線的語句都有影響，因此要小心使用。該引數可以幫助減少優化期間佔用的時間和資源。雖然這樣可以減少優化所需的時間和資源，但是同時也會增加生成非最佳資料訪問計劃的風險。

DB2_REDUCED_OPTIMIZATION=5

注意： 只有在 IBM 明確建議的情況下，才應該設定該引數。

回頁首

資料庫管理器配置引數

表 4 展示了資料庫管理器配置引數：

以例項使用者的身份，輸入以下命令，更新資料庫管理器配置：

db2 "update dbm cfg using query_heap_sz 32768"
db2 "update dbm cfg using maxagents 1000"
db2 "update dbm cfg using sheapthres 50000"
db2 "update dbm cfg using health_mon off"
db2 "update dbm cfg using aslheapsz 60"
db2 "update dbm cfg using rqrioblk 65535"
db2 "update dbm cfg using federated no"

注意： 如果需要聯邦資料庫支援，不能將 FEDERATED 設為 NO。

回頁首

資料庫配置引數

用於所有資料庫的引數

表 5 展示了應該為所有資料庫設定的資料庫配置引數：

以例項使用者的身份，輸入以下命令，為所有資料庫更新資料庫配置。注意將 DBNAME 改為實際的資料庫名稱：

db2 "update db cfg for DBNAME using applheapsz 4096"
db2 "update db cfg for DBNAME using app_ctl_heap_sz 1024"
db2 "update db cfg for DBNAME using stmtheap 8192"
db2 "update db cfg for DBNAME using dbheap 2400"
db2 "update db cfg for DBNAME using locklist 1000"
db2 "update db cfg for DBNAME using logfilsiz 1000"
db2 "update db cfg for DBNAME using logprimary 12"
db2 "update db cfg for DBNAME using logsecond 20"
db2 "update db cfg for DBNAME using logbufsz 128"
db2 "update db cfg for DBNAME using avg_appls 5"
db2 "update db cfg for DBNAME using locktimeout 30"
db2 "update db cfg for DBNAME using maxlocks 70"
db2 "update db cfg for DBNAME using maxappls automatic"

用於 JCR 資料庫的引數

表 6 展示了應該為 JCR 資料庫設定的資料庫引數：

以例項使用者的身份，輸入以下命令，更新特定於 JCRDB 的資料庫配置。將 JCRDB 改為實際的資料庫名稱：

db2 "update db cfg for JCRDB using dbheap 4800"
db2 "update db cfg for JCRDB using sortheap 4096"
db2 "update db cfg for JCRDB using applheapsz 16384"
db2 "update db cfg for JCRDB using app_ctl_heap_sz 20000"
db2 "update db cfg for JCRDB using stmtheap 16384"
db2 "update db cfg for JCRDB using num_iocleaners 11"
db2 "update db cfg for JCRDB using num_ioservers 11"

回頁首

資料庫調優

資料庫效能對於從 WCM 獲得良好效能十分重要。本文和 IBM WebSphere Portal Version 6.0 Tuning Guide 中提到的維護任務和實踐對於 WebSphere Portal 在我們的實驗環境中正確、高效地執行非常關鍵。在您的生產環境中，可能還需要進行一些其他的資料庫維護和調優。要了解關於 DB2 管理、調優和監視的更詳細資訊，請參考 DB2 Information Center（參加 參考資料）。

校正序列

在建立資料庫時，DB2 允許對序列進行校正（collate）。這將對效能產生影響。雖然在本報告描述的場景中，使用 UCA400_NO collation 實際上對吞吐率沒有影響，但是它會產生高得多的資料庫 CPU 開銷。然而，在單獨的調查評測中，UCA400_NO 校正（collation）的使用對於某些 WCM 事務建立有明顯的影響。根據經驗，需要對特定於地區的特殊資料排序需求和可能導致的更高的資料庫 CPU 開銷之間進行權衡。當我建立資料庫時，沒有指定任何 COLLATE 選項。

將 JCR 表變為穩定狀態

JCR 模式的 DB2 配置將大多數表標記為 VOLATILE CARDINALITY。在初始填充期間，這是正確的，因為很多表從 0 行或少數幾行增長到多行。這個屬性告訴 DB2 優化器不要信任表統計資訊，因為這些統計資訊表明表非常小，如果信任這些統計資訊，優化器會像往常一樣利用針對小表的索引對錶進行掃描。而一旦資料庫達到穩定狀態，則希望優化器根據編目統計資訊選擇最佳訪問計劃（要獲得關於如何維護這些統計資訊的建議，請參閱後面的小節）。為此，執行以下命令：

db2 -x -r "nonVolatile.db2" "select rtrim(concat('alter table ', concat(rtrim(tabSchema),
concat('.', concat(rtrim(tabname), ' not volatile'))))) from syscat.tables where type='T'
and volatile='C' and tabSchema='JCR'"

db2 -v -f "nonVolatile.db2"

回頁首

持續的資料庫維護

Runstats 和 reorg

DB2 賴以高效執行的兩個資料庫屬性是資料庫編目統計資訊和資料在表中的物理組織。在資料庫的生命週期中，特別是經過重大的資料修改（插入、更新和刪除），例如填充階段之後，應該定期地重新計算編目統計資訊。由於計算這些統計資訊時需要佔用很多的資源，因此最好在非繁忙時段、低需求階段或者 portal 離線時執行這種維護。DB2 runstats 命令用於計算和記錄關於表、索引和列的統計資訊。在我們的環境中，我使用了兩種方法來計算這些統計資訊。 我推薦的形式是：

+
db2 "runstats on table tableschema.tablename on all columns with distribution
on all columns and sampled detailed indexes all allow write access"

這些選項使優化器可以為複雜的 SQL 確定最佳訪問計劃。對於計算編目統計資訊，一種更簡單、更方便的方法是：

db2 reorgchk update statistics on table all

該命令不僅計算並記錄一些相同的編目統計資訊，它還產生一個報告，通過檢視該報告可以發現表組織方面的問題。但是，我發現該命令所產生的資訊不夠充分，不足以讓優化器為複雜的 SQL（特別是對於 JCR 資料庫的查詢）選擇高效的訪問計劃。如果您想使用一種與 reorgchk 命令一樣方便，同時又能提供優化器所需的詳細統計資訊的方法，那麼可以使用下面的命令：

db2 -x -r "runstats.db2" "select rtrim(concat('runstats on table',
concat(rtrim(tabSchema), concat('.',concat(rtrim(tabname),
' on all columns with distribution on all columns and sampled detailed
indexes all allow write access'))))) from syscat.tables where type='T'"

db2 -v -f "runstats.db2"

在生產環境中，重組所有的表是無法接受的。為了確定哪些表可以通過重組獲益，可以使用下面的命令：

db2 reorgchk current statistics on table all > "reorgchk.txt"

表名旁的三個列當中至少有一個列中標記有 * 符號的表，這就是需要重組的表。對於需要重組的表，使用以下命令：

db2 reorg table tableschema.tablename

監視

快照監視用於識別資料庫在一段時間內的行為。它被進一步用於對系統進行細微調節，以及發現與效能相關的問題。

要啟用快照監視，首先需要啟用不同的監視器。有兩種方式可以啟用監視器。一種方式是配置資料庫管理器，在例項級別啟用監視，另一種方式是在特定的時候為當前會話啟用監視。

要在例項級別啟用預設的監視，使用以下命令：

db2 update dbm cfg using DFT_MON on

其中 DFT_MON 在以下值當中取值：

DFT_MON_BUFPOOL DFT_MON_LOCK DFT_MON_SORT DFT_MON_STMT DFT_MON_TABLE DFT_MON_TIMESTAMP DFT_MON_UOW

要為當前會話啟用監視，使用命令：

db2 update monitor switches using MON_SWITCH on

其中 MON_SWITCH 在以下值當中取值：

注意：由於活動的監視器會增加對 CPU 的使用，所以應當只在必要時才啟用所有的監視器。

要獲得當前被啟用的監視器開關，可以使用以下命令：

db2 get monitor switches

要獲得資料庫的快照，可以執行以下命令：

db2 get snapshot for all on DBNAME >snap.out

監視 DB2 系統的另一種方法是 db2top。可以從 http://www.alphaworks.ibm.com/tech/db2top 獲得這個實用程式。

緩衝池分析

分享這篇文章…… 提交到 Digg 釋出到 del.icio.us Slashdot 一下！

緩衝池是在從磁碟讀取或修改表和索引資料頁時，用於快取它們的記憶體。由於緩衝池允許從記憶體而不是磁碟訪問資料，因此可以提高資料庫系統的效能。由於記憶體訪問比磁碟訪問快很多，因此資料庫管理器讀寫磁碟的次數越少，效能就越好。

由於 DB2 v8 中沒有 SYSIBMADM.BP_HITRATIO 表，我編寫了兩個儲存過程，用於計算緩衝池的命中率：bphr 顯示實際資料庫的緩衝池命中率，而 bphr_all 顯示例項中所有活動資料庫的緩衝池命中率。

可以使用以下命令來呼叫這兩個儲存過程：

db2 call bphr
db2 call bphr_all

連線到一個資料庫之後，可以使用以下命令安裝這兩個儲存過程：

db2 -td@ -f bphr.db2

                
CREATE PROCEDURE bphr ()
SPECIFIC tessus_bphr LANGUAGE SQL DYNAMIC RESULT SETS 1

BEGIN
  DECLARE res CURSOR WITH RETURN FOR
WITH bp_snap (snapshot_timestamp, database, bufferpool, bp_hr, data_hr, 
              idx_hr, page_clean_ratio )
AS
(
  SELECT snapshot_timestamp, SUBSTR(db_name,1,16), SUBSTR(bp_name,1,32),
  CASE
    WHEN ((pool_data_p_reads > 0 OR pool_index_p_reads > 0) AND 
          (pool_data_l_reads > 0 OR pool_index_l_reads > 0))
      THEN
        DECIMAL( ((1-(double(pool_data_p_reads + pool_index_p_reads)/
        DOUBLE(pool_data_l_reads + pool_index_l_reads+1)) )*100.0),3,1 )
      ELSE
        NULL
      END CASE,
      CAST( (CAST( pool_data_l_reads - pool_data_p_reads
        AS DOUBLE)*100.0)/(pool_data_l_reads+1) AS DECIMAL(3,1)),
      CAST( (CAST( pool_index_l_reads - pool_index_p_reads 
        AS DOUBLE)*100.0)/(pool_index_l_reads+1) AS DECIMAL(3,1)),
      CAST( (CAST( pool_async_data_writes + pool_async_index_writes
        AS DOUBLE)*100.0)/(pool_data_writes+pool_index_writes+1) 
        AS DECIMAL(3,1))
  FROM TABLE(snapshot_bp('',-1)) AS BP
  ORDER BY 2,3
)
SELECT snapshot_timestamp, database, bufferpool, bp_hr, data_hr, idx_hr 
FROM bp_snap;

  OPEN res;
END@

CREATE PROCEDURE bphr_all ()
SPECIFIC tessus_bphr_all LANGUAGE SQL DYNAMIC RESULT SETS 1

BEGIN
  DECLARE res CURSOR WITH RETURN FOR
WITH bp_snap (snapshot_timestamp, database, bufferpool, bp_hr, data_hr, 
              idx_hr, page_clean_ratio )
AS
(
  SELECT snapshot_timestamp, SUBSTR(db_name,1,16), SUBSTR(bp_name,1,32),
  CASE
    WHEN ((pool_data_p_reads > 0 OR pool_index_p_reads > 0) AND 
          (pool_data_l_reads > 0 OR pool_index_l_reads > 0))
      THEN
        DECIMAL( ((1-(double(pool_data_p_reads + pool_index_p_reads)/
        DOUBLE(pool_data_l_reads + pool_index_l_reads+1)) )*100.0),3,1 )
      ELSE
        NULL
      END CASE,
      CAST( (CAST( pool_data_l_reads - pool_data_p_reads
        AS DOUBLE)*100.0)/(pool_data_l_reads+1) AS DECIMAL(3,1)),
      CAST( (CAST( pool_index_l_reads - pool_index_p_reads 
        AS DOUBLE)*100.0)/(pool_index_l_reads+1) AS DECIMAL(3,1)),
      CAST( (CAST( pool_async_data_writes + pool_async_index_writes
        AS DOUBLE)*100.0)/(pool_data_writes+pool_index_writes+1) 
        AS DECIMAL(3,1))
  FROM TABLE(snapshot_bp(CAST(NULL AS VARCHAR(128)),-1)) AS BP
  ORDER BY 2,3
)
SELECT snapshot_timestamp, database, bufferpool, bp_hr, data_hr, idx_hr 
FROM bp_snap;

  OPEN res;
END@

在 DB2 9 中，可以使用這兩個儲存過程，也可以使用以下 SQL 語句來獲得緩衝池命中率：

db2 "select snapshot_timestamp, substr(db_name,1,10) as dbname,
substr(bp_name,1,18) as bufferpool, total_hit_ratio_percent as total,
data_hit_ratio_percent as data, index_hit_ratio_percent as index
from sysibmadm.bp_hitratio"

理想的緩衝池命中率是高於 96%。首先可以嘗試增加緩衝池大小，看能否提高命中率。如果命中率仍然較低，那麼可能需要重新設計表空間和緩衝池的邏輯佈局。

可以使用以下命令線上更改緩衝池的大小：

db2 alter bufferpool BPNAME immediate size NUMBER_OF_PAGES

回頁首

目錄伺服器調優

我的評測使用 IBM Tivoli Directory Server (ITDS) version 5.2 作為目錄伺服器。該目錄伺服器配置方面的細節與 IBM WebSphere Portal Version 6.0 Tuning Guide 中指定的 AIX ITDS V5.2 目錄伺服器的配置相同。

WebSphere Portal Service 屬性

WebSphere Portal 有很多可配置的服務；每個服務都有一些可用的引數。本節描述我對哪些服務進行了不同於 IBM WebSphere Portal Version 6.0 Tuning Guide 的調優。

惟一進行了不同調優的服務是 Cache Manager Service。對於這個服務，除了下面表中列出的更改外，我接受了 WebSphere Portal 的預設設定：

結束語

本教程展示了調優 WebSphere Portal WCM 和 DB2 環境涉及的步驟。您應該看到了這個環境的獨特之處，對它進行調優時需要作一些特殊的考慮。本文展示了那些應該設定為指定值的各種登錄檔變數和一些資料庫管理器及資料庫配置引數的重要性。最後，您看到了如何維護 DB2 系統，使之隨系統增長仍然可以高效執行。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14751907/viewspace-371907/，如需轉載，請註明出處，否則將追究法律責任。