WAS關(guān)鍵性能參數(shù)配置及異常分析

1、WAS關(guān)鍵性能參數(shù)配置及異常分析文檔更改歷史記錄日期版本號(hào)描述作者2013-02-03V1.0編寫(xiě)林茂楠目錄WAS關(guān)鍵性能參數(shù)配置及異常分析11.WAS性能關(guān)鍵參數(shù)配置41.1 JVM（Java虛擬機(jī)）41.2 GC（詳細(xì)垃圾回收）41.3 Web Container61.4 Data Source數(shù)據(jù)源71.4.1安裝數(shù)據(jù)源驅(qū)動(dòng)71.4.2配置全局?jǐn)?shù)據(jù)源變量71.4.3配置數(shù)據(jù)源驅(qū)動(dòng)71.4.4配置數(shù)據(jù)源81.4.5 Database連接池的參數(shù)配置111.5 其它關(guān)鍵參數(shù)121.5.1 EJB分發(fā)共享內(nèi)存參數(shù)122.WAS性能分析工具122.1 WAS性能監(jiān)控配置122.2 WAS性能監(jiān)控

2、123.WAS異常分析123.1 關(guān)鍵日志文件123.1 javacore、heapdump分析143.1.1 javacore的分析143.1.2 heapdump的分析201.WAS性能關(guān)鍵參數(shù)配置1.1 JVM（Java虛擬機(jī)）Heapsize（-Xms和-Xmx）：heapsize的大小依賴(lài)于系統(tǒng)平臺(tái)和具體的應(yīng)用等多種因素。最大heapsize需要小于機(jī)器的物理內(nèi)存，一般來(lái)說(shuō)，默認(rèn)最小heapsize為256m。例如NG設(shè)置的JVM為-Xms 512m，-Xmx 2048m。如果在WAS應(yīng)用服務(wù)器未設(shè)置JVM參數(shù)或者設(shè)置JVM參數(shù)不合理，會(huì)有可能告成應(yīng)用服務(wù)器處理效率低或者造成OutO

3、fMemoryError的情況。備注：2m代表是2m的程序?qū)ο?.2 GC（詳細(xì)垃圾回收）GC（Garbage Collection）：當(dāng)需要分配的內(nèi)存空間不再使用的時(shí)候，JVM將調(diào)用垃圾回收機(jī)制來(lái)回收內(nèi)存空間。一般來(lái)說(shuō)，良好的GC狀態(tài)需要保證相鄰兩次垃圾回收的平均間隔時(shí)間應(yīng)當(dāng)是單次垃圾回收所需時(shí)間的至少5-6倍。GC的調(diào)優(yōu)是通過(guò)在模擬壓力的情況下不斷調(diào)整最大最小heapsize來(lái)實(shí)現(xiàn)的，并不是heapsize設(shè)置越大越好。通過(guò)在WAS應(yīng)用服務(wù)器配置詳細(xì)垃圾回收，從而可以使WAS在運(yùn)行時(shí)生成native_stderr.log，native_stderr.log日志幫助分析JVM在進(jìn)行GC垃圾回

4、收時(shí)的數(shù)據(jù)，包括回收時(shí)間（頻率）、長(zhǎng)存區(qū)（tenured）在收回前、收回中、收回后的對(duì)比。在實(shí)際的應(yīng)用中可通過(guò)native_stderr.log來(lái)發(fā)現(xiàn)WAS JVM的性能問(wèn)題并做出相應(yīng)的JVM參數(shù)調(diào)整?；厥涨耙淮危夯厥兆钚乱淮吻昂髢纱蜧C運(yùn)行對(duì)比，可看行回收間隔為7S，一次GC運(yùn)行時(shí)間不到1S，JVM的設(shè)置在較理想的狀態(tài)值。例如出現(xiàn)OOM的情況，可通過(guò)WAS產(chǎn)生的javacore及heapdump進(jìn)行分析定位，并結(jié)合GC產(chǎn)生的native_stderr.log進(jìn)行分析確認(rèn)：GC耗時(shí)超過(guò)21S ，GC內(nèi)存回收前的可用內(nèi)存為0，GC內(nèi)存回收后的可用內(nèi)存為0%，可用JVM內(nèi)存已耗盡，說(shuō)明系統(tǒng)使用存在

5、內(nèi)存泄露（OOM）現(xiàn)象。1.3 Web ContainerWeb容器J2EE標(biāo)準(zhǔn)的實(shí)現(xiàn)，為serverlet和jsp提供運(yùn)行環(huán)境。例如，當(dāng)一個(gè)HTTP請(qǐng)求通過(guò)要訪問(wèn)一個(gè)web組件（通常是一個(gè)serverlet或者是jsp），通常是將這個(gè)請(qǐng)求轉(zhuǎn)發(fā)給web container處理完畢后再返回到web server。Web Container的調(diào)優(yōu)是通過(guò)對(duì)Web Container傳輸鏈中各個(gè)通道（TCP、HTTP、WebContainer）的參數(shù)調(diào)整進(jìn)行的。這些參數(shù)包括諸如ThreadPool的最大最小值，buffer大小，timeout時(shí)間的大小，keep-alive的值等等。一般配置WebCo

6、ntainer即可，需根據(jù)業(yè)務(wù)的實(shí)際使用情況進(jìn)行值的配置，主要業(yè)務(wù)在WAS達(dá)到的應(yīng)用連接數(shù)，其它值為默認(rèn)值即可：1.4 Data Source數(shù)據(jù)源1.4.1安裝數(shù)據(jù)源驅(qū)動(dòng)拷貝驅(qū)動(dòng)JAR包到/usr/websphere/AppServer/lib目錄，如：cp ojdbc6.jar /usr/websphere/AppServer/lib1.4.2配置全局?jǐn)?shù)據(jù)源變量登陸控制臺(tái)：https:/WAS IP:9043/ibm/console/logon.jsp（1）“環(huán)境” “WebSphere變量”，選擇作用域?yàn)椋杭?所有域（2）增加全局變量：ORACLE_JDBC_DRIVER_PATH “

7、新建”名稱(chēng)：ORACLE_JDBC_DRIVER_PATH值：/usr/websphere/AppServer/lib備注：NG未用到全局變量。1.4.3配置數(shù)據(jù)源驅(qū)動(dòng)增加ORACLE驅(qū)動(dòng)：資源JDBCJDBC提供程序1.4.4配置數(shù)據(jù)源根據(jù)系統(tǒng)規(guī)劃需求，按規(guī)劃配置數(shù)據(jù)源。（1）登陸控制臺(tái)：https:/WAS IP:9043/ibm/console/logon.jsp；（2）資源-JDBC-數(shù)據(jù)源 新增數(shù)據(jù)源（“名稱(chēng)和JDNI名稱(chēng)”與規(guī)劃的ID和VALUE對(duì)應(yīng)）；備注：建議數(shù)據(jù)庫(kù)地址不直接使用IP而用主機(jī)名代替，方便后續(xù)維護(hù)（3）J2C認(rèn)證數(shù)據(jù)配置登陸賬號(hào)信息；備注：修改完數(shù)據(jù)源需要重啟動(dòng)W

8、AS服務(wù)（重啟動(dòng)應(yīng)用也不能生效）1.4.5 Database連接池的參數(shù)配置在各自的數(shù)據(jù)源可配置該數(shù)據(jù)源的連接池大小配置，選擇資源-JDBC-數(shù)據(jù)源-連接池，可配置連接池最小、最大連接數(shù)及連接超時(shí)時(shí)限等。1.5 其它關(guān)鍵參數(shù)1.5.1 EJB分發(fā)共享內(nèi)存參數(shù)用root用戶(hù)登錄命令行修改每個(gè)WebSphere安裝路徑的$WasIntallPath/AppServer/deploytool/itp/ejbdeploy.sh內(nèi)容，根據(jù)主機(jī)資源情況將EJB分發(fā)共享內(nèi)存上限從默認(rèn)256M修改為更大的值?！?JAVA_CMD -Xbootclasspath/a:$ejbd_bootpath -Xms256

9、m Xmx256m”2.WAS性能分析工具2.1 WAS性能監(jiān)控配置后續(xù)補(bǔ)寫(xiě)2.2 WAS性能監(jiān)控后續(xù)補(bǔ)寫(xiě)3.WAS異常分析3.1 關(guān)鍵日志文件（1）SystemOut.log、SystemErr.log、was_server/logs/ffdc目錄的日志查看最新WAS異常時(shí)段的SystemOut.log、SystemErr.log日志，搜索Error、Exception、Thread、OutOfMemory等相關(guān)關(guān)鍵字進(jìn)行分析定位異常情況。查看保留ffdc目錄的日志文件，ffdc工具試圖在發(fā)生非正常的情況時(shí)，自動(dòng)獲取并保留關(guān)鍵信息，其中包含堆棧跟蹤、異常發(fā)生時(shí)的環(huán)境等相關(guān)信息?？山Y(jié)合Syst

10、emOut.log、SystemErr.log等相關(guān)日志進(jìn)行異常的定位。NGBOSS的SystemOut.log、SystemErr.log日志存放位置：/waslogs目錄（2）native_stderr.log、native_stdout.lognative_stderr.log日志可查看出JVM垃圾回收的記錄及每次GC的間隔時(shí)間及運(yùn)行時(shí)間，如下圖所示：紅色標(biāo)識(shí)分別為：GC運(yùn)行時(shí)間點(diǎn)、垃圾回收前內(nèi)存情況、垃圾回收后內(nèi)存情況、GC運(yùn)行時(shí)間長(zhǎng)。從結(jié)果可看出JVM中已無(wú)內(nèi)存可再回收，JVM處于OOM的狀態(tài)?？梢钥闯鰆ava/lang/OutOfMemoryError：(3) 收集Web serv

11、er服務(wù)器日志收集IHS日志（access_log、error_log）及插件Plug-in（plugin-cfg.xml and http_plugin.log）的日志及配置文件，查看是否出現(xiàn)異常信息。例如http_plugin.log，可能提示一個(gè)連接無(wú)法正常發(fā)送到相關(guān)WAS Server，不過(guò)嘗試連接其它WAS Server，這種情況可能是無(wú)法連接的Server處理較繁忙的狀態(tài)或者網(wǎng)絡(luò)中斷。3.1 javacore、heapdump分析java程序在遇到致命異常時(shí)，為了能夠保留java應(yīng)用發(fā)生致命錯(cuò)誤前的運(yùn)行狀態(tài)，jvm在無(wú)法工作前產(chǎn)生兩個(gè)文件，分別為javacore及heapdump文

12、件。3.1.1 javacore的分析Javacore文件是一個(gè)java進(jìn)程的快照，javacore文件中可以顯示當(dāng)時(shí)運(yùn)行這個(gè)java進(jìn)程的所有線程的運(yùn)行情況。 我們可以利用javacore來(lái)分析和判斷一些故障，如：（1）100% CPU Usage（2）Crash或OOM（3）Hang/Performance Javacore目錄的設(shè)置在環(huán)境條目分別填入：名稱(chēng)值描述IBM_HEAPDUMPDIR/wasdump/heapdump/Heapdump重定向IBM_JAVACOREDIR/wasdump/heapdump/Javacore重定向IBM_COREDIR/wasdump/heapdum

13、p/Core重定向 Javacore的文件名Javacore文件的命名是根據(jù)系統(tǒng)的計(jì)算得來(lái)的，如javacore24802.1026159146.txt，而且是唯一的。下列是根據(jù)操作系統(tǒng)的不同產(chǎn)生的名字不同：NG現(xiàn)AIX環(huán)境下產(chǎn)生的javacore文件：javacore.20130128.180057.13041766.0024 Javecore的產(chǎn)生Javacore的產(chǎn)生有兩種方式，一種是自動(dòng)產(chǎn)生，一種是通過(guò)kill -3 PID進(jìn)行生成。自動(dòng)產(chǎn)生Javacore，一般都是出現(xiàn)OOM的情況。 Javacore的分析（1）直接打開(kāi)Javacore文件查看直接打開(kāi)后，可以看到關(guān)鍵信息，可以看到每

14、一個(gè)線程的執(zhí)行棧，以stacktrace的方式顯示。通過(guò)對(duì)javacore的分析可以得到應(yīng)用是否“卡”在某一點(diǎn)上，即在某 一點(diǎn)運(yùn)行的時(shí)間太長(zhǎng)。例如：可看出有java/lang/OutOfMemoryError的異常信息。（2）運(yùn)用javacore分析工具下載javacore運(yùn)行工具jca:運(yùn)行java Xmx1024m jar jca.jar:可看線程運(yùn)行情況：請(qǐng)求線程可分為以下幾種狀態(tài)：死鎖，Deadlock（重點(diǎn)關(guān)注） 執(zhí)行中，Runnable（重點(diǎn)關(guān)注） 等待資源，Waiting on condition（重點(diǎn)關(guān)注） 等待監(jiān)控器檢查資源，Waiting on monitor暫停，Susp

15、ended對(duì)象等待中，Object.wait()阻塞，Blocked（重點(diǎn)關(guān)注） 停止，Parked Deadlock：死鎖線程，一般指多個(gè)線程調(diào)用間，進(jìn)入相互資源占用，導(dǎo)致一直等待無(wú)法釋放的情況。Runnable：一般指該線程正在執(zhí)行狀態(tài)中，該線程占用了資源，正在處理某個(gè)請(qǐng)求，有可能正在傳遞SQL到數(shù)據(jù)庫(kù)執(zhí)行，有可能在對(duì)某個(gè)文件操作，有可能進(jìn)行數(shù)據(jù)類(lèi)型等轉(zhuǎn)換。Waiting on condition：等待資源，如果堆棧信息明確是應(yīng)用代碼，則證明該線程正在等待資源，一般是大量讀取某資源，且該資源采用了資源鎖的情況下，線程進(jìn)入等待狀態(tài)，等待資源的讀取。又或者，正在等待其他線程的執(zhí)行等。Block

16、ed：線程阻塞，是指當(dāng)前線程執(zhí)行過(guò)程中，所需要的資源長(zhǎng)時(shí)間等待卻一直未能獲取到，被容器的線程管理器標(biāo)識(shí)為阻塞狀態(tài)，可以理解為等待資源超時(shí)的線程。這種情況在was的日志中，一般可以看到CPU饑渴，或者某線程已執(zhí)行了XX秒的信息。一般建議的分析邏輯： 在內(nèi)存溢出時(shí)，分析Javacore文件中的線程內(nèi)容，可以采用自下而上的分析方法。 查看有多少線程被設(shè)置了Blocked狀態(tài)，這些線程是在執(zhí)行什么請(qǐng)求，并且到了堆棧最后一步在等待什么資源 查找到這些Blocked線程等待的執(zhí)行線程編號(hào) 繼續(xù)查找該線程，分析其堆棧與狀態(tài)與監(jiān)控器的記錄的信息。一般這些線程會(huì)處于Waiting on condition狀態(tài)，

17、因?yàn)檫@些線程也是因?yàn)橘Y源遲遲未獲取到或者執(zhí)行時(shí)間過(guò)長(zhǎng)一直處于等待狀體，進(jìn)一步導(dǎo)致隊(duì)列中其他需要訪問(wèn)這些資源的線程都被設(shè)置為Blocked狀態(tài)。 在找到線程后，我們就可以初步將問(wèn)題縮小到哪些業(yè)務(wù)應(yīng)用請(qǐng)求存在問(wèn)題，是哪一個(gè)類(lèi)與哪一行代碼，其等待的資源是什么。備注：具體情況具體分析，后續(xù)需根據(jù)實(shí)際經(jīng)驗(yàn)完善。3.1.2 heapdump的分析heapdump文件是一個(gè)二進(jìn)制文件，它保存了某一時(shí)刻jvm堆中對(duì)象情況，這種文件需要相應(yīng)的工具進(jìn)行分析，可以從網(wǎng)上下載最新的分析工具。因打開(kāi)heapdump文件對(duì)系統(tǒng)內(nèi)存要求較高，一般只能借用64位的服務(wù)器進(jìn)行分析問(wèn)題。HeapDump的生成開(kāi)關(guān)export IBM_HEAPDUMP=trueexport IBM_HEAP_DUMP=trueexport IBM_HEAPDUMP_OUTOFMEMORY=trueexport IBM_JAVADUMP_OUTOFMEMORY=trueexport IBM_JAVACORE_OUTOFMEMORY=trueexport IBM_HEAPDUMPDIR=注意：通常