基本性能檢查以確保最佳效能

每當遇到效能問題時，首先會執行基本性能檢查。這些協助確保符合基本配置、維護需求，並協助識別是否有資源瓶頸。 Product Master隨附一組基本配置及維護準則。您可以遵循下列準則，以協助避免一般效能問題。本文件彙總如何使用 pimSupport.sh Script 來快速檢查建議的配置及維護狀態。

症狀

Product Master 提供慢速效能。

原因

配置不正確，且存在許多舊版本列可能會導致效能變慢。

診斷問題

每當您遇到效能問題時，第一個作業應該是回答下列問題:

資料庫是否已正確配置?
現行表格和索引佈置是否符合預設綱目?
表格及索引統計資料是否為最新?
是否定期刪除舊版本?
快取是否已配置足夠的空間並顯示大於 97% 的快取命中率?
應用程式或資料庫伺服器端是否有任何 CPU 或記憶體相關瓶頸?

如果任何問題的答案是 no，則您必須採取動作來更正狀況。

如何驗證配置及維護性能

使用 pimSupport.sh Script 來執行基本性能檢查。下面提供使用此 Script 及範例輸出的範例:


$TOP/bin/pimSupport.sh -b
=======================================
Software and System Stack: starting....Done
Setup and Configuration: starting......Done
Implementation & Deployment: starting..Done
Runtime Statistics: starting...........Done
=======================================

Collecting information on DB2
COMMON_INFO_COLLECT_INFO_SH WebSphere Application Server
All results can be found in $TOP/tmp/pimSupport_MM_DD_YYYY__HH_MM.tar.gz file

當使用者在系統上工作時，以及在您正常觀察效能問題的狀況下，最好執行 Script。該 Script 會收集超出您可能需要的資訊，但在此基本性能檢查的環境定義中，您會在產生的保存檔 .../health_check/healthCheckResult.out中找到所有需要的資訊。

解譯基本性能檢查的 healthCheckResult.out 內容: healthCheckResult.out 檔案的內容會隨著 IBM® Db2® 或 Oracle 是用作後端資料庫伺服器，以及 Script 執行所在的版次和版本而略有不同。

資料庫配置

With DB2 as backend DB server:
====================================================
Generating database configuration checklist...
====================================================
db2  DB2 v10.1
====================================================
DB2_SKIPDELETED         INSTALL GUIDE VALUE = NO/OFF FOR DB2 v10.1 : DATABASE SETTING OFF
DB2_EVALUNCOMMITTED     INSTALL GUIDE VALUE = NO/OFF FOR DB2 v10.1 : DATABASE SETTING  OFF
DB2_SKIPINSERTED        INSTALL GUIDE VALUE = NO/OFF FOR DB2 v10.1 : DATABASE SETTING  OFF
DB2_PARALLEL_IO         INSTALL GUIDE VALUE = * : DATABASE SETTING  * 
mon_heap_sz             INSTALL GUIDE VALUE = AUTOMATIC : DATABASE SETTING = AUTOMATIC    90
sheapthres              INSTALL GUIDE VALUE = 0 : DATABASE SETTING =  0
dft_queryopt            INSTALL GUIDE VALUE = 5 : DATABASE SETTING =  5
applheapsz              INSTALL GUIDE VALUE = AUTOMATIC : DATABASE SETTING =  AUTOMATIC   CURRENT VALUE =  10240
....

With Oracle as backend DB server:
oracle  11.2.0.1.0
====================================================
db_block_size		       INSTALL_GUIDE_VALUE = 8192			  DATABASE SETTING = 8192 
query_rewrite_enabled	       INSTALL_GUIDE_VALUE = TRUE			  DATABASE SETTING = TRUE 
processes		       INSTALL_GUIDE_VALUE >= 200			  DATABASE SETTING = 800 
open_cursors		       INSTALL_GUIDE_VALUE >= 600			  DATABASE SETTING = 600 
db_cache_size		       INSTALL_GUIDE_VALUE = 0 OR >= 1 GB		  DATABASE SETTING = 0 
shared_pool_size	       INSTALL_GUIDE_VALUE = 0 OR >= 200 MB		  DATABASE SETTING = 0 
optimizer_index_caching        INSTALL_GUIDE_VALUE = 90 			  DATABASE SETTING = 90 
optimizer_index_cost_adj       INSTALL_GUIDE_VALUE = 50 			  DATABASE SETTING = 50 
GATHER_STATS_PROG	       INSTALL_GUIDE_VALUE = TRUE			  DATABASE SETTING = TRUE 
STATS ESTIMATE PERCENT	       INSTALL_GUIDE_VALUE = 100			  DATABASE SETTING = 100

第一個直欄顯示參數，第二個直欄顯示建議的設定，第三個直欄顯示現行設定。現行設定應該符合建議的設定。在資源配置的情況下，現行設定的值應該高於建議的值。

如需建議設定的詳細資料，請參閱安裝及設定資料庫。

綱目驗證

從標題「索引」狀態開始，您會尋找已變更及遺漏「表格及索引」的報告。如果未報告任何內容，則狀態是正確的。如果報告中列出離差，則您必須釐清它們。

附註: 您的環境必須符合預設資料庫綱目。在大部分安裝中，這將確保最佳效能。

如果資料庫管理者建議修改現行綱目 (例如，刪除、新增或修改索引) ，則建議使用產品支援重新檢查這些變更，以避免潛在負面影響。這也將確保綱目變更，這將改善所有客戶的效能，並在未來成為預設綱目的一部分。

Indexes status
 _______________________________________________________________
|Changed Tables                                                 |
|===============================================================|
|  There are no changed tables                                  |
|_______________________________________________________________|
 _______________________________________________________________
|Missing Tables                                                 |
|===============================================================|
|  There are no missing tables                                  |
|_______________________________________________________________|
 _______________________________________________________________
|Changed Indexes                                                |
|===============================================================|
|                                                               |
|  ICTG_CHI_0                                                   |
|    Current Column Structure:                                  |
|      CHI_CHILD_ID                                             |
|      CHI_NEXT_VERSION_ID                                      |
|      CHI_PARENT_ID                                            |
|      CHI_VERSION_ID                                           |
|      CHI_CAT_TREE_ID                                          |
|      CHI_COMPANY_ID                                           |
|    Required Column Structure:                                 |
|      CHI_CHILD_ID                                             |
|      CHI_NEXT_VERSION_ID                                      |
|      CHI_VERSION_ID                                           |
|      CHI_COMPANY_ID                                           |
|      CHI_CAT_TREE_ID                                          |
|      CHI_PARENT_ID                                            |
|                                                               |
|_______________________________________________________________|
 _______________________________________________________________
|Missing Indexes                                                |
|===============================================================|
|  ICTG_CHI_0 CHI_CHILD_IDCHI_NEXT_VERSION_ID....IDCHI_PARENT_ID|
|_______________________________________________________________|

任何變更或遺漏的索引都不會觸發任何產品故障，但可能會導致執行緩慢的 SQL (延遲查詢) 導致整體產品效能變慢。為了更正綱目偏差，您可以在下列目錄中檢查 *.sql 檔是否有必要的綱目佈置:

$TOP/src/db/schema/gen/[db2|oracle]

例如，如果您想要查看索引 ICTG_CHI_0:

cd $TOP/src/db/schema/gen/db2
grep -i ICTG_CHI_0 *.sql   ==> this shows file idx_ctg_catalog.sql containing the definition
open idx_ctg_catalog.sql and search for chi_0

表格及索引統計資料

為了取得最佳效能，它必須是資料庫表格，且索引統計資料是最新的。這可確保資料庫最佳化工具可以選擇最佳 (最快) 存取計劃，以擷取每一個 SQL 查詢的資料。

在檔案中， healthCheckResult.out 您會找到標題為「前次維護」的區段，其中顯示每一個表格及索引的前次統計資料更新時間。

With DB2 as backend DB server:
SCHEMA_NAME TABLE_NAME                     STATS_TIME       NO_OF_ROWS  PROFILE_USED 
 ----------- ------------------------------ ---------------- ----------- 
 SCHEMA    TCTG_ITA_ITEM_ATTRIBUTES       2013-06-10 08:30     2002101 RUNSTATS ON TABLE "SCHEMA"."TCTG_ITA_ITEM_ATTRIBUTES" ON ALL COLUMNS WITH DISTRIBUTION ON ALL COLUMNS AND SAMPLED DETAILED INDEXES ALL 
 SCHEMA    TPFM_PSD_SCHEDULE_DETAIL       2013-06-23 21:00     1129281 RUNSTATS ON TABLE "SCHEMA"."TPFM_PSD_SCHEDULE_DETAIL" ON ALL COLUMNS WITH DISTRIBUTION ON ALL COLUMNS AND SAMPLED DETAILED INDEXES ALL 
...

SCHEMA_NAME        INDEX_NAME                STATS_TIME       NO_OF_ROWS  COLUMNS 
 ------------------ ------------------------- ---------------- ----------- 
 SCHEMA           ICTG_ITA_1                2013-06-10 08:30     2025185 +ITA_NODE_ID+ITA_VALUE_NUMERIC+ITA_NEXT_VERSION_ID+ITA_VERSION_ID+ITA_CATALOG_ID+ITA_OCCURRENCE_ID+ITA_ITEM_ID 
 SCHEMA           ICTG_ITA_3                2013-06-10 08:30     2024506 +ITA_NODE_ID+ITA_VALUE_STRING_IGNORECASE+ITA_NEXT_VERSION_ID+ITA_VERSION_ID+ITA_CATALOG_ID+ITA_OCCURRENCE_ID+ITA_ITEM_ID 
 SCHEMA           ICTG_ITA_2                2013-06-10 08:30     2023320  
...


With Oracle as backend DB server:
TABLE_NAME                       LAST_ANALYZED  NUM_OF_ROWS       SAMPLE_SIZE          TABLESPACE_NAME

======================================================================================================

TCTG_NOA_NODE_ATTRIBUTES         18-JUN-13           896814            896814          USERS
TPFM_PPR_PROFILE                 18-JUN-13           892969            892969          USERS
...


INDEX_NAME                       TABLE_NAME                       LAST_ANALYZED     NUM_ROWS SAMPLE_SIZE DISTINCT_KEYS           STATUS   TABLE_SPACE_NAME

==========================================================================================================================================================

ICTG_NOA_3                       TCTG_NOA_NODE_ATTRIBUTES         18-JUN-13           896814      896814        896814           VALID    INDX
ICTG_NOA_4                       TCTG_NOA_NODE_ATTRIBUTES         18-JUN-13           896814      896814             6           VALID    INDX
...

請確定統計資料是最新的，並使用詳細取樣比例。

若為 Db2 型安裝，您應該會看到:

RUNSTATS ON TABLE .... ON ALL COLUMNS WITH DISTRIBUTION ON ALL COLUMNS AND SAMPLED DETAILED INDEXES ALL

若為 Oracle 型安裝: 應該配置 100% 取樣比例，當 num_rows 直欄顯示的數字與每個表格/索引的 sample_size 相同時即會確認。如需相關資訊，請參閱：

舊版本計數

隨著越來越多的舊版本橫列累積，整體效能可能會大幅降低。因此，處理舊版本是一項重要的行政工作。如需相關資訊，請參閱：

舊物件版本。

您可以透過觀察 healthCheckResult.out中的「表格上的現行/舊列計數比例」區段，快速檢查在一段時間內是否累計了太多舊版本列。

current/old row count ratios on tables
====================================================

table name current version row count old version row count ratio current/old row count
---------- ------------------------- --------------------- ---------------------------
noa        22117                     49925                           .44
nod        3673                      7469                            .49
noh        3342                      6959                            .48
icm        181523                    164387                         1.10
ita        1013552                   988832                         1.02
itm        95660                     99404                           .96
itd        95660                     99403                           .96

對於選取的表格，會提供現行及舊版本列計數，以及現行/舊版本列計數的比例。如果您看到表格 itm 或 itd 的現行版本列計數超過 100,000 ，且比例小於 0.3，則強烈建議刪除舊版本。

快取命中使用率

Product Master 具有部分 Product Master 物件的內建快取機制。確保高快取命中率可能是最佳效能的關鍵。

如需相關資訊，請參閱快取管理。

HealthCheckResult.out 檔案在 "PIM CACHE SNAPSHOT" 區段中為您提供每一個服務之現行快取配置及使用率的快速概觀:

PIM CACHE SNAPSHOT:                     
Title                                   Current  Max       Cache    Cache      Hit
                                        C. Size  C. Size   Hits     Requests   Percentage
...
--------------appsvr_LORIOT----------------
Spec Cache                              400      126       15953    16089      99%        
Spec Key To Current Start Version Cache 400      257       15999    16287      98%        
Spec Key Version to Start Version Cache 400      13        0        6          0%         
Lookup Table Cache                      500      24        1610     1636       98%        
Role Cache                              2000     13        111872   111885     100%       
Access Cache                            5000     0         0        0          0%         
Spec Name Cache                         2000     7         29       37         78%        
Attribute Collections Cache             500      92        3335     3563       94%        
WSDL Cache                              0        0         0        0          0%         
Workflow Definition Cache               250      3         63       67         94%        
Script Cache                            1000     17        139      170        82%        
Catalog Cache                           100      2         245      247        99%        
Catalog Definition Cache                2000     49        500      554        90%        
Node Id Cache                           2000     127       800      927        86%        
View Cache                              5000     35        865      954        91%
...

「現行快取大小」會顯示現行配置設定，而「快取大小上限」會顯示當時快取了多少物件。

每當您發現「快取大小上限」達到定義的上限，且常用快取上的「命中百分比」低於 95% 時，就應該反覆地增加每一個快取 (如 mdm-cache-config.properties 檔案中所定義) 的 maxElementsInMemory 設定 (只要有足夠的記憶體)。快取是否高度使用，可由「快取命中」和「快取要求」值來判斷。

如果您需要監視快取命中使用率，則可以執行下列指令來觸發快取 Snapshot:

$JAVA_RT com.ibm.ccd.common.wpcsupport.util.SupportUtil --cmd=getRunTimeCacheDetails

檢查資源使用率

在 Product Master 或資料庫伺服器端上的資源不足，可能會觸發尖峰使用時間期間的效能問題。這可以是:

伺服器端 CPU 瓶頸
伺服器端記憶體瓶頸

若要檢查伺服器端瓶頸，您可以使用各種公用程式，例如

top, topas,
sar, vmstat

或 nmon。要使用的選項取決於您的喜好設定。基於監視目的， nmon 可能更好，但需要安裝個別套件以取得相關資訊)。

如果長時間 CPU 使用率超過 90% ，或伺服器開始交換記憶體，則您必須調查資源使用率過高的原因，並最終提供更多可用的資源。

如果部分 Product Master 服務 JVM 在上限上使用其記憶體，因而導致記憶體回收時間過長，也可能會出現效能問題。 healthCheckResult.out 檔案為您提供服務 JVM 記憶體配置詳細資料，以及每一個服務的一次記憶體用量 Snapshot。

== 2. SETUP and CONFIGURATION           
-----------------------------------------------------------------------------------------
PARAMETER                               VALUE               
SCHEDULER_MEMORY_FLAG                   -Xmx1024m -Xms48m   
QUEUEMANAGER_MEMORY_FLAG                -Xmx64m -Xms48m     
APPSVR_MEMORY_FLAG                      -Xmx1024m -Xms256m  
ADMIN_MEMORY_FLAG                       -Xmx64m -Xms48m     
WORKFLOWENGINE_MEMORY_FLAG              -Xmx1024m -Xms48m   
EVENTPROCESSOR_MEMORY_FLAG              -Xmx64m -Xms48m    

JVM LEVEL SERVICE MEMORY SNAPSHOT:      
Service Short Name            Service Type        Total Mem(MB)    Total Used Mem(MB) 
workflowengine_LORIOT         workflowengine      73815            34535
scheduler_LORIOT              scheduler           71584            30339
appsvr_LORIOT                 appsvr              268435           88690
queuemanager_LORIOT           queuemanager        64601            26746
admin_LORIOT                  admin               50331            6327
eventprocessor_LORIOT         eventprocessor      66647            28488

在 SETUP 和 CONFIGURATION 下，您會找到每一個 JVM (-Xmx) 的已配置記憶體大小上限，並且在 JVM LEVEL SERVICE MEMORY SNAPSHOT 區段中，您會看到針對每一個服務 JVM 所配置的記憶體數量、目前配置的記憶體數量以及使用中的記憶體數量。如果「記憶體總計」和「已使用記憶體總計」接近所定義的 -Xmx 設定，則可能指出個別服務需要更多記憶體，且 -Xmx 設定需要增加。只能透過執行下列指令來觸發 JVM 層次服務記憶體 Snapshot:

$JAVA_RT com.ibm.ccd.common.wpcsupport.util.SupportUtil --cmd=getRunTimeMemDetails

附註: 此指令不應以高間隔執行，因為它會在每一個 JVM 上觸發記憶體回收。

如果 JVM 記憶體用量是一個問題，則需要設定更詳細的監視。例如，針對個別服務啟用 verbose: gc。

如需 Java™ 資料堆大小調整的一般提示，請參閱:

如何執行資料堆大小調整

IBM Product Master 12.0 Fix Pack 10

作業系統: AIX、 Linux及 Windows (僅限工作台)

基本性能檢查以確保最佳效能

症狀

原因

診斷問題