系統上線後偶有宕機,而且每次都是出現在相同的某兩個業務點上,多次對程序進行代碼檢查,認真分析後,仍舊沒有解決問題。
宕機後,產生上G的dump文件和javacore文件,苦於沒有分析經驗,很久沒有找到解決問題的方案。查找資源後,發現兩個軟件,即 heapAnalyzer 和 jca。前者分析dump文件,後者分析javacore文件。對於 heapAnalyzer而言,在 windows 環境下,打不開AIX上產生的dump文件(如:heapdump.20090520.092248.430562.phd),而且本機的windows環境也沒有可分配的那麼大的內存來啟動該軟件,迫不得己,直接在生產環境上使用 heapAnalyzer 。文件成功打開,但是分析結果的可讀性不強,非 WebLogic 專業人員估計看不太懂,大體的意思就是程序的某個地方加載了大量的對象。如下圖所示:
後來使用jca分析javacore文件後,得到解決的辦法。原來是因為 JDK 的問題,我們使用的是: J2RE 5.0 IBM J9 2.3 AIX ppc-32 build j9vmap3223-20070201 ,這個SR4的版本有個問題就是,限定了類加載器可加載的類數量,默認為 8192 ,如果超過此限制,就會拋出 OutOfMemory 的錯誤。郁悶啊,這事都趕上了。
分析javacore:
# cd /home
# ls
Test.class guest nmon startVmstat.sh
Test.java heapAnalyzer ojdbc14.jar startWebLogic.out
classes12.jar jca oracle startWebLogic.sh
dumpfile jdk64_15 start.log stop.log
esaadmin lost+found start.sh stop.sh
# cd jca
# ls
jca.properties.xml license tdv.cfg
jca37.jar readme.zip
# java -Xmx1000m -jar jca37.jar
分析結果中,有Process ID,這個應該對應數據庫服務器的執行進程,如果時間允許,我們可以通過topas可以看到該進程一直在執行。同時,分析結果還有Current Thread ,就是對應引起錯誤的應用服務器線程,使用該線程的名稱作為關鍵字在log裡搜索,我們可以發現引起錯誤的原因。
最後,jca會給出分析後的建議,Recommended -Xmxcl setting (only for IBM Java 5.0, up to and including Service Refresh 4 (build date:February 1st ,2007)) : 10,649 or greater。
注意此段描述:
NOTE: Only for Java 5.0 Service Refresh 4 (build date:February 1st, 2007) and older. When you use delegated class loaders, the JVM can create a large number of ClassLoader objects. On IBM Java 5.0 Service Refresh 4 and older, the number of class loaders that are permitted is limited to 8192 by default and an OutOfMemoryError exception is thrown when this limit is exceeded. Use the -Xmxcl parameter to increase the number of class loaders allowed to avoid this problem, for example to 25000, by setting -Xmxcl25000, until the problem is resolved.
郁悶了N久的問題得以解決,哈哈,心情大好。。。