主機系統CICS健康檢查手冊.docxVIP

主機系統CICS和CPSM健康檢查手冊 目 錄第 1 章CICS和CPSM檢查方法概述31.1檢查內容31.2數據收集3第 2 章CICS和CPSM系統配置檢查42.1系統配置檢查內容42.2CICS和CPSM配置描述42.3CICS與其他子系統連接描述42.4數據案例5第 3 章CICS和CPSM運行性能檢查73.1CICS運行性能檢查概述73.2交易完成速率和響應時間73.3交易量執(zhí)行情況83.4達到MXT和TCLASS情況103.5DSA/EDSA使用情況123.6TDQ和TSQ使用情況133.7CICS CONNECTION使用情況153.8DB2 Attachment153.9DBCTL Attachment173.10TCB POOL使用情況193.11VSAM文件檢查193.12LOGSTREAM檢查21第 4 章CICS和CICSPLEX 錯誤信息檢查234.1CICS LOG信息檢查234.2聯機STORAGE VIOLATION檢查234.3聯機交易DUMP檢查24第 1 章 CICS和CPSM檢查方法概述1.1 檢查內容本CICS和CPSM健康檢查主要檢查CICS運行的整體性能，資源使用瓶頸、系統錯誤等；而對于與應用程序相關的交易的性能，則不在本檢查范圍內。概括講，主要包括以下內容： CICS和CPSM的配置檢查對CICS和CPSM的整體配置進行評估。 CICS系統運行性能檢查檢查CICS運行的資源使用情況，發(fā)現資源使用瓶頸。 CICS系統錯誤信息檢查檢查影響CICS系統穩(wěn)定運行的出錯情況。1.2 數據收集CICS和CPSM檢查基于如下系統數據： CICS和CPSM系統參數，包括: CICS啟動JCL， CICS SYSIN參數， CSD資源定義， CPSM DREP資源定義 CICS LOGSTREAM定義 CICS End-of-day統計報告數據（SMF 110） LOGSTREAM統計數據（SMF 88） CMAS EYULOG和CICS JOB LOG第 2 章 CICS和CPSM系統配置檢查2.1 系統配置檢查內容對檢查環(huán)境的CICS和CPSM配置進行描述，并對配置情況進行檢查和評估。2.2 CICS和CPSM配置描述數據來源CICS啟動JCL，CICS啟動參數SYSIN，CICS資源定義CSD，CPSM資源定義DREP。配置描述包括： CPSM的拓撲結構 CAS的LPAR分布，連接狀況 CMAS的LPAR分布，功能（MP或Non MP），連接狀況 MAS的LPAR分布，功能（TOR，AOR，FOR等），連接狀況 MAS GROUP分類情況 CPSM WLM描述 WLM SPEC，GROUP，DEF定義描述 WLM 交易路由控制（DYNAMIC或STATIC） WLM 交易 AFFINITY情況 CPSM RTA描述 RTA SPEC，DEF定義描述檢查要點 應當充分利用CPSM 交易動態(tài)路由的功能，減少交易的AFFINITY。 對于CPSM，建議實施CICSDB2 CONNECT的監(jiān)控功能。2.3 CICS與其他子系統連接描述數據來源CICS啟動JCL，CICS啟動參數SYSIN，CICS資源定義CSD。配置描述包括： CICSDB2 INTERFACE CICSMQ INTERFACE CICS RLS使用情況 CICS CF STRUCTURE使用情況，如NAMING COUNTER，TS SERVER，和CFDT2.4 數據案例第 3 章 CICS和CPSM運行性能檢查3.1 CICS運行性能檢查概述CICS運行性能檢查主要是通過CICS EOD的STATISTICS和WLM RMF報告檢查CICS各部分運行的狀況，目的在于消除CICS運行的性能瓶頸。CICS運行性能檢查部分包括： 交易完成速率和響應時間 交易量執(zhí)行情況 達到MXT和TCLASS情況 DSA/EDSA使用情況 TDQ和TSQ使用情況 CICS CONNECTION使用情況 DB2 Attachment TCB POOL使用情況 VSAM文件檢查 LOGSTREAM檢查3.2 交易完成速率和響應時間數據來源來自RMF WLM報表中，交易完成速率和交易響應時間數據,每隔15分鐘為一個數據采集點。 TRANSACTIONS TRANS.-TIME HHH.MM.SS.TTT AVG 0.00 ACTUAL 107 MPL 0.00 EXECUTION 106 ENDED 129734 QUEUED 0 END/S 144.15 R/S AFFINITY 0檢查要點根據WLM定義的GOAL檢查交易的平均響應時間和完成速率。交易的完成速率（END/S）反映CICS的壓力，交易的平均響應時間（ACTUAL）反映了交易運行的性能。如果交易的平均響應時間出現異常，則需要對異常情況進行分析。造成平均響應時間異常的原因主要有資源的瓶頸（如STORAGE SHORT），資源的鎖（如文件，DB2的LOCK），交易錯誤（如大量的ABEND）等。數據案例從上圖分析, 核心系統的交易峰值在384筆/秒左右,平均交易響應時間在0.12秒以內; 基本達到響應時間要求在0.3秒以內的目標.3.3 交易量執(zhí)行情況數據來源來自CICS STATISTICS EOD報表:TRANSACTION MANAGER STATISTICSTotal number of active user transactions 檢查要點Total number of active user transactions ：反映CICS總體的交易量。通過交易量的檢查，其一可以了解CICS交易總量，其二可以了解各CICS和各LPAR交易負載均衡情況。負載均衡情況反映了各個CICS或LPAR承受的壓力大小，理想情況是各CICS或LPAR的負載能夠大致相同，避免個別CICS或LPAR壓力過大，CPU等資源承受不了。從CICS看，各TOR和各AOR的交易量應當大體均衡；從LPAR看，各LPAR上的交易量也應當大體均衡。如果交易量出現較大的不均衡，應當調查不均衡的原因，并進行改進。數據案例數據分析核心系統除PB21交易量相對較外, 其他AOR上的交易分布相對均衡。每個AOR的一天內處理交易數, 在160萬筆左右。數據表明核心兩個LPAR上處理的交易量, 還是比較均勻的。3.4 達到MXT和TCLASS情況數據來源來自CICS STATISTICS EOD報表:MXT達到情況檢查：TRANSACTION MANAGER STATISTICSCurrent MAXTASKS limit ：Peak number of active user transactions ：Times the MAXTASKS limit reached ：Peak number of MAXTASK queued user transactions ：Total number of MAXTASK delayed user transactions ：TCLASS達到情況檢查：TRANSACTION CLASS STATISTICSPeak Act，Peak Queued，Times MaxAct檢查要點Peak number of active user transactions 反映交易的最大活動數，值應當小于最大的定義值Current MAXTASKS limit，即Times the MAXTASKS limit reached應當為0。如果Times the MAXTASKS limit reached不為0，則Peak number of MAXTASK queued user transactions和Total number of MAXTASK delayed user transactions可以反映出達到MXT的嚴重性。Peak Act，Peak Queued，Times MaxAct反映了TCLASS的使用情況，Times MaxAct值應當為0。如果出現MXT或者TCLASS達到的情況，可以考慮適當增加MXT或TCLASS的最大設定值。因為WLM用CICS最大任務數這個參數來確定PB（Performance Block）的數量以進行數據收集。如果最大任務數設定較高，則會導致嚴重的開銷問題；同時活動交易增多，同樣會造成其他的資源瓶頸，如DSA/EDSA等。檢查案例核心AOR的MXT為200, 沒有到達MXT的情況發(fā)生, 目前PEAK MAX TASK是123以下.核心TOR的MXT為200, 各TOR有最多175次到達MXT的情況貸記卡AOR的MXT為100, 沒有到達MXT的情況發(fā)生.貸記卡TOR的MXT為100, 沒有到達MXT的情況發(fā)生核心系統上的其他CICS分區(qū), 沒有到達MXT的情況發(fā)生核心系統AOR有TCALSS TCLCBB10最6次到達TCLASS purge threshold, 最多24個交易被QUEUE的情況, 此TCLASS定義了AIPS和TLUA交易, 定義Max Act為10, Purge Thresh為5, 如果不是有意對這兩個交易做這種限制, 建議加大Max Act數據分析總體正常, 但仍有調整的余地。建議如果CPU資源如果不特別緊張, 可以加大核心TOR的MXT到250。3.5 DSA/EDSA使用情況數據來源來自CICS STATISTICS EOD報表，包括DSA和EDSA。STORAGE MANAGER STATISTICSCurrent DSA size :Peak DSA Size :Times went short on storage ：檢查要點DSA/EDSA反映CICS STORAGE使用情況，當DSA/EDSA使用達到定義值時，CICS會進入SHORT ON STORAGE狀態(tài)，CICS交易如果無法得到內存而無法執(zhí)行，CICS性能將會受到嚴重影響。正常情況下，DSA應該有1M以上的空余空間，EDSA應該有50M以上的空余空間；并且在一段時間內，DSA/EDSA的使用量沒有明顯的變化趨勢。如果出現DSA的SHORT ON STORAGE，除了考慮擴大DSA空間外，還應該減少/消除程序對16M線下STORAGE的使用；如果出現EDSA的SHORT ON STORAGE，可以考慮增加CICS EDSA的大小。數據案例核心CICS DSA/EDSA使用情況數據分析核心環(huán)境和貸記卡環(huán)境AOR的DSA/EDSA的PEAK使用率都不高, DSA/EDSA有相當富余空間。3.6 TDQ和TSQ使用情況數據來源來自CICS STATISTICS EOD報表。TDQ使用情況TRANSIENT DATA Control intervals : Peak control intervals used : Intrapartition buffers : Intrapartition buffer waits : Peak intrapartition buffer waits : Number of strings : Intrapartition string waits : Peak string waits : TSQ使用情況TEMPORARY STORAGENumber of control intervals available : Peak control intervals in use : Temporary storage buffers : Buffer waits : Peak users waiting on buffer : Temporary storage strings : Peak number of strings in use : Times string wait occurred : Peak number of users waiting on string : 檢查要點對于TDQ和TSQ，主要關心三個方面：Buffer Waits：應該避免出現Buffer Wait。如果出現Buffer Waits在CICS Storage富裕的情況下，可以適當增加Buffer值。String Waits：應該避免出現String Wait。如果出現String Waits在CICS Storage富裕的情況下，可以適當增加String值。Peak Control Intervals In Used： 應當與Number of control intervals available有較大距離。如果達到或接近Number of control intervals available ，則需要增加TSQ或TDQ Dataset的大小，或者對TDQ或TSQ進行清理。數據案例數據顯示核心環(huán)境AOR和MOR的TSQ的TS buffer需要增加。AOR的TS=(,100,50)增加為TS=(,110,50); MOR的TS=(,3,3) 增加為TS=(,6,3)3.7 CICS CONNECTION使用情況數據來源來自CICS STATISTICS EOD報表。ISC/IRC SYSTEM AND MODE ENTRIESPeak outstanding allocatesFailed link allocates Failed allocates due to sessions in use 檢查要點CICS連接是由一組SESSION構成。如果SESSION數目不足，會影響CICS間交易的路由及通信。主要關注是否有Peak outstanding allocates，如果不為0，則需要考慮要增加SESSION數。數據案例核心環(huán)境, AOR-TOR, AOR-EOR, AOR-AOR, AOR-MOR的SESSIONS個數都在正常范圍內, 無Peak outstanding allocates。3.8 DB2 Attachment數據來源來自CICS STATISTICS EOD報表。DB2 CONNECTION STATISTICS TCB LimitPeak number of TCBsCurrent Pool Thread LimitNumber of Pool Thread WaitsPeak number of Pool Threads in useDB2ENTRY STATISTICSThread LimitThread HWMPthread LimitPthread HWMThread Waits/OverflowsReadyq HWM檢查要點CICSDB2 Interface反映CICS交易使用DB2 THREAD情況，主要關注THREAD WAIT發(fā)生的情況，包括POOL和DB2ENTRY THREAD。 如果Peak Number TCBs達到或接近TCB Limit，則需要考慮增加CICSDB2 TCB數 如果出現POOL THREAD WAIT或者ENTRY Thread Waits/Overflows，則可以考慮增加相應的Thread Limit，同時TCB Limit也要相應增加 如果調整了TCB Limit，SYSIN參數中的MAXOPENTCBS也要進行相應的調整檢查案例核心環(huán)境各AOR的pool thread wait 最多有92次, thread Waits/Overflows最多有75次, 同時TCB的PEAK使用都接近TCBLIMT=80.鑒于目前核心環(huán)境對應DB2 member的CTHREAD總數為300*2=600, 而Protected thread總數為20*8=160, 相對富余; 而TCB LIMIT總數80*8=640. 基于Total DB2 TCB LIMIT Total DB2 CTHREAD的原則, 我們建議如下:1) 在與DB2專家協商后, 將CTHTEAD至少增加為330(最好到400, 由于目前XX行DB2版本為7.1,可先增加到330), 這樣總數為330*2=660.2) 在CTHREAD增加的基礎上, 相應同步上調DB2 entry DP20DB2E 的 thread limit, 比如從50到80, 總數為 80 * 8 = 6403) 目前只定義了一個Priority為HIGH的DB2 entry, 建議增加一類Priority為EQUAL的DB2 entry; IBM建議將交易數量較大,但DB2資源使用較少的HOT交易定義為HIGH, 而將其他HOT交易定義為EQUAL. 使用DB2 entry可增加thread re-use, 提高訪問DB2效率.4) 目前Pool Thread Priority 定義為HIGH, 這是值得討論的, 建議改為EQUAL.3.9 DBCTL Attachment數據來源來自CICS STATISTICS 報表，收集數據時，需要斷開CICS與IMS的連接；打印STATISTICS報表時，使用TYPE=DBCTL參數。DBCTL SESSION TERMINATION STATISTICS _ DBCTL identifier : DBCTL RSE name : Minimum number of threads : Maximum number of threads : Times minimum threads hit : Times maximum threads hit : Elapsed time at maximum threads : Peak number of thread TCBs : Successful PSB schedules :檢查要點CICSIMS Interface反映CICS交易使用IMS THREAD情況，主要關注Times maximum threads hit發(fā)生的情況。 如果Times maximum threads hit數值較高，則需要考慮增加CICSIMS MAXTHRD數量檢查案例核心環(huán)境AOR:CI21SA11的DBCTL SESSION使用情況：DBCTL SESSION TERMINATION STATISTICS _ DBCTL identifier : IS21 DBCTL RSE name : IS21 Minimum number of threads : 25 Maximum number of threads : 35 Times minimum threads hit : 287 Times maximum threads hit : 15566 Elapsed time at maximum threads : 000-00:47:06.96 Peak number of thread TCBs : 35 Successful PSB schedules : 3641675) 其中Times maximum threads hit達到15566 次，Elapsed time at maximum threads時間達到47分鐘，Times minimum threads hit也有287次。我們建議調整MAXTHRD到40，并繼續(xù)監(jiān)控THREAD使用情況。如果在各個LPAR交易均衡的狀況下，Times maximum threads hit依然很高，可以考慮繼續(xù)調整MAXTHRD數量。3.10 TCB POOL使用情況數據來源來自CICS STATISTICS EOD報表。CICS TCB Pool StatisticsPeak TCBs attached in this TCB Pool . . . . . . : Max TCB Pool limit . . . . . . . . :檢查要點當Peak TCBs attached in this TCB Pool達到或接近Max TCB Pool limit定義時，需要擴大Max TCB Pool Limit值。其中，需重點關注MAXOPENTCBS。數據案例核心AOR MAXOPENTCBS目前定義為120, 單個AOR最多使用到112, 需擴充。核心AOR沒有發(fā)現L9 OPEN TCB被使用, 建議客戶可以花較少代價改造為OPENAPI threadsafe程序, 提高程序執(zhí)行性能.3.11 VSAM文件檢查數據來源來自CICS STATISTICS EOD報表；VSAM LISTCATEOD報表：FILES - Performance Information0 File Active Excl Cntl Name Strings Strings Current Total Highest Data Index ConflictsVSAM LISTCAT;SPLITS-CI ， SPLITS-CA檢查要點對于VSAM 文件的檢查，首先需要檢查文件是否出現String Wait，這可以通過檢查EOD報表中文件性能部分的Wait On Strings統計信息。如果文件出現String Wait，則在CSD 文件定義中，需要增大String Number。其次，需要檢查文件是否出現大量的CI/CA Split。大量的CI/CA Split對文件和交易的性能有很大的影響。數據案例1) 發(fā)現如下文件使用RLS模式來訪問ESDS文件: File Dataset Name Dataset Name Base Dataset Name (If Applicable) Type RLS _ CSCLOG ESS.PRD.CS10V.CSCLOG ESDS YESPMLF ESS.PRD.AP121V.PMLF ESDS YESPML2 ESS.PRD.AP121V.PML2 ESDS YESPRMLOG ESS.PRD.ISS.CICS.PRMLOG ESDS YES2) 發(fā)現1個文件存在較多STRING WAIT0FILES - Performance Information +_ 0 File Wait On Strings Excl Cntl Name Strings Total HWM Data Index Conflicts + _ GADTLOGB 1 10927 3 3 2 0 3) 使用LISTCAT檢查VSAM文件的CI/CA SPLIT數據分析1) 在RLS模式下使用ESDS文件會造成CICS hung和可用性的問題,如果一個CICS分區(qū)在寫ESDS文件時發(fā)生錯誤, 則此ESDS文件可能被LOCK, 直到CICS分區(qū)被重起。 所以不建議在RLS模式下不使用ESDS文件。2)GADTLOGB是ESDS文件,且只有ADD操作, 這是合理的, 不需要增加STRING。3.12 LOGSTREAM檢查數據來源來自SMF TYPE 88檢查要點對DFHLOG和DFHSHUNT檢查，避免出現STAGE DATASET FULL情況，避免出現LOG DASD SHIFT情況。數據分析核心系統和貸記卡系統: peak # offload次數核心系統為24, 貸記卡系統為21 可見少量DASD SHIFT AOR在域“BYT DELETED INTERIM ST W/DASD”, 頻繁出現很大數目 說明”BYT DEL