案例分析

系統上線後偶有當機，而且每次都是出現在相同的某兩個業務點上，多次對程式進行程式碼檢查，認真分析後，仍舊沒有解決問題。 當機後，產生上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.