WAS關鍵性能參數配置及異常分析

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

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

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

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

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

6、ntainer即可，需根據業(yè)務的實際使用情況進行值的配置，主要業(yè)務在WAS達到的應用連接數，其它值為默認值即可：1.4 Data Source數據源1.4.1安裝數據源驅動拷貝驅動JAR包到/usr/websphere/AppServer/lib目錄，如：cp ojdbc6.jar /usr/websphere/AppServer/lib1.4.2配置全局數據源變量登陸控制臺：https:/WAS IP:9043/ibm/console/logon.jsp（1）“環(huán)境”> “WebSphere變量”，選擇作用域為：集群=所有域（2）增加全局變量：ORACLE_JDBC_DRIVER_PA

7、TH “新建”>名稱：ORACLE_JDBC_DRIVER_PATH值：/usr/websphere/AppServer/lib備注：NG未用到全局變量。1.4.3配置數據源驅動增加ORACLE驅動：資源>JDBC>JDBC提供程序1.4.4配置數據源根據系統(tǒng)規(guī)劃需求，按規(guī)劃配置數據源。（1）登陸控制臺：https:/WAS IP:9043/ibm/console/logon.jsp；（2）資源->JDBC->數據源 新增數據源（“名稱和JDNI名稱”與規(guī)劃的ID和VALUE對應）；備注：建議數據庫地址不直接使用IP而用主機名代替，方便后續(xù)維護（3）J2C認證數據

8、配置登陸賬號信息；備注：修改完數據源需要重啟動WAS服務（重啟動應用也不能生效）1.4.5 Database連接池的參數配置在各自的數據源可配置該數據源的連接池大小配置，選擇資源->JDBC->數據源->連接池，可配置連接池最小、最大連接數及連接超時時限等。1.5 其它關鍵參數1.5.1 EJB分發(fā)共享內存參數用root用戶登錄命令行修改每個WebSphere安裝路徑的$WasIntallPath/AppServer/deploytool/itp/ejbdeploy.sh內容，根據主機資源情況將EJB分發(fā)共享內存上限從默認256M修改為更大的值。“$JAVA_CMD -Xbo

9、otclasspath/a:$ejbd_bootpath -Xms256m Xmx256m”2.WAS性能分析工具2.1 WAS性能監(jiān)控配置后續(xù)補寫2.2 WAS性能監(jiān)控后續(xù)補寫3.WAS異常分析3.1 關鍵日志文件（1）SystemOut.log、SystemErr.log、was_server/logs/ffdc目錄的日志查看最新WAS異常時段的SystemOut.log、SystemErr.log日志，搜索Error、Exception、Thread、OutOfMemory等相關關鍵字進行分析定位異常情況。查看保留ffdc目錄的日志文件，ffdc工具試圖在發(fā)生非正常的情況時，自動獲取并保

10、留關鍵信息，其中包含堆棧跟蹤、異常發(fā)生時的環(huán)境等相關信息。可結合SystemOut.log、SystemErr.log等相關日志進行異常的定位。NGBOSS的SystemOut.log、SystemErr.log日志存放位置：/waslogs目錄（2）native_stderr.log、native_stdout.lognative_stderr.log日志可查看出JVM垃圾回收的記錄及每次GC的間隔時間及運行時間，如下圖所示：紅色標識分別為：GC運行時間點、垃圾回收前內存情況、垃圾回收后內存情況、GC運行時間長。從結果可看出JVM中已無內存可再回收，JVM處于OOM的狀態(tài)。可以看出java/

11、lang/OutOfMemoryError：(3) 收集Web server服務器日志收集IHS日志（access_log、error_log）及插件Plug-in（plugin-cfg.xml and http_plugin.log）的日志及配置文件，查看是否出現異常信息。例如http_plugin.log，可能提示一個連接無法正常發(fā)送到相關WAS Server，不過嘗試連接其它WAS Server，這種情況可能是無法連接的Server處理較繁忙的狀態(tài)或者網絡中斷。3.1 javacore、heapdump分析java程序在遇到致命異常時，為了能夠保留java應用發(fā)生致命錯誤前的運行狀態(tài)，j

12、vm在無法工作前產生兩個文件，分別為javacore及heapdump文件。3.1.1 javacore的分析Javacore文件是一個java進程的快照，javacore文件中可以顯示當時運行這個java進程的所有線程的運行情況。Ø 我們可以利用javacore來分析和判斷一些故障，如：（1）100% CPU Usage（2）Crash或OOM（3）Hang/Performance Ø Javacore目錄的設置在環(huán)境條目分別填入：名稱值描述IBM_HEAPDUMPDIR/wasdump/heapdump/<servername>Heapdump重定向IBM_

13、JAVACOREDIR/wasdump/heapdump/<servername>Javacore重定向IBM_COREDIR/wasdump/heapdump/<servername>Core重定向Ø Javacore的文件名Javacore文件的命名是根據系統(tǒng)的計算得來的，如javacore24802.1026159146.txt，而且是唯一的。下列是根據操作系統(tǒng)的不同產生的名字不同：NG現AIX環(huán)境下產生的javacore文件：javacore.20130128.180057.13041766.0024Ø Javecore的產生Javacore

14、的產生有兩種方式，一種是自動產生，一種是通過kill -3 PID進行生成。自動產生Javacore，一般都是出現OOM的情況。Ø Javacore的分析（1）直接打開Javacore文件查看直接打開后，可以看到關鍵信息，可以看到每一個線程的執(zhí)行棧，以stacktrace的方式顯示。通過對javacore的分析可以得到應用是否“卡”在某一點上，即在某 一點運行的時間太長。例如：可看出有java/lang/OutOfMemoryError的異常信息。（2）運用javacore分析工具下載javacore運行工具jca:運行java Xmx1024m jar jca.jar:可看線程運行

15、情況：請求線程可分為以下幾種狀態(tài)：死鎖，Deadlock（重點關注） 執(zhí)行中，Runnable（重點關注） 等待資源，Waiting on condition（重點關注） 等待監(jiān)控器檢查資源，Waiting on monitor暫停，Suspended對象等待中，Object.wait()阻塞，Blocked（重點關注） 停止，Parked Deadlock：死鎖線程，一般指多個線程調用間，進入相互資源占用，導致一直等待無法釋放的情況。Runnable：一般指該線程正在執(zhí)行狀態(tài)中，該線程占用了資源，正在處理某個請求，有可能正在傳遞SQL到數據庫執(zhí)行，有可能在對某個文件操作，有可能進行數據類型等

16、轉換。Waiting on condition：等待資源，如果堆棧信息明確是應用代碼，則證明該線程正在等待資源，一般是大量讀取某資源，且該資源采用了資源鎖的情況下，線程進入等待狀態(tài)，等待資源的讀取。又或者，正在等待其他線程的執(zhí)行等。Blocked：線程阻塞，是指當前線程執(zhí)行過程中，所需要的資源長時間等待卻一直未能獲取到，被容器的線程管理器標識為阻塞狀態(tài)，可以理解為等待資源超時的線程。這種情況在was的日志中，一般可以看到CPU饑渴，或者某線程已執(zhí)行了XX秒的信息。一般建議的分析邏輯：Ø 在內存溢出時，分析Javacore文件中的線程內容，可以采用自下而上的分析方法。Ø 查看

17、有多少線程被設置了Blocked狀態(tài)，這些線程是在執(zhí)行什么請求，并且到了堆棧最后一步在等待什么資源Ø 查找到這些Blocked線程等待的執(zhí)行線程編號Ø 繼續(xù)查找該線程，分析其堆棧與狀態(tài)與監(jiān)控器的記錄的信息。一般這些線程會處于Waiting on condition狀態(tài)，因為這些線程也是因為資源遲遲未獲取到或者執(zhí)行時間過長一直處于等待狀體，進一步導致隊列中其他需要訪問這些資源的線程都被設置為Blocked狀態(tài)。Ø 在找到線程后，我們就可以初步將問題縮小到哪些業(yè)務應用請求存在問題，是哪一個類與哪一行代碼，其等待的資源是什么。備注：具體情況具體分析，后續(xù)需根據實際經驗完

18、善。3.1.2 heapdump的分析heapdump文件是一個二進制文件，它保存了某一時刻jvm堆中對象情況，這種文件需要相應的工具進行分析，可以從網上下載最新的分析工具。因打開heapdump文件對系統(tǒng)內存要求較高，一般只能借用64位的服務器進行分析問題。HeapDump的生成開關export IBM_HEAPDUMP=trueexport IBM_HEAP_DUMP=trueexport IBM_HEAPDUMP_OUTOFMEMORY=trueexport IBM_JAVADUMP_OUTOFMEMORY=trueexport IBM_JAVACORE_OUTOFMEMORY=trueexport IBM_HEAPDUMPDIR=<directory_path>注意