【WebLogic故障處理】一次嚴重的WebLogic記憶體洩漏問題處理過程

[quote]原帖由 [i]mfkqwyc86[/i] 於 2010-10-26 20:49 發表 [url=http://www.itpub.net/redirect.php?goto=findpost&pid=16646868&ptid=1361828][img]http://www.itpub.net/images/common/back.gif[/img][/url]
問題描述


最近應用伺服器WebLogic服務每天均出現多次當機情況，嚴重影響業務的使用


目的：由於某些原因，開發商不能修改程式，本次主要降低當機頻繁，保障春節期間正常執行。


環境：Linux ，Sun JDK 1.4.2 SR4，WebLogic Server 8.1.3（兩臺）

問題分析及處理1、
Weblogic執行緒超時

日誌中經常出現與資料庫相關的執行緒執行時間超過10分鐘或30分鐘而且超時，這種情況對資料庫SQL語句進行最佳化處理後正常。


1、
WebLogic JVM記憶體洩漏

主要表現為程式中存在許多物件佔用記憶體不能被回收，特別是大物件，導致頻繁FULL GC垃圾回收，而每次垃圾回收後又不能清理這些物件而回收佔用空間，則系統的響應時間則越長，當新物件多次申請空間時又不能滿足需求，最終出現記憶體溢位而WebLogic當機。
如下圖，其中(a),(b),(c)均是使用XXXX頁面期間產生的3個執行緒（189,193,194）佔用情況，WebLogic自身及其它物件使用只佔用了140M。
此問題經過多次分析，均是由XXXX頁面的訪問引起。


頁面附圖：記憶體洩漏.gif

1、
應用伺服器CPU佔用比較高

經檢查，發現佔用CPU高的程式主要是Java程式，即WebLogic Server執行程式，透過分析JDK GC日誌，發現在GC垃圾回收佔用系統資源嚴重，而FULL GC垃圾回收又是整個垃圾回收的重點，而每次FULL GC垃圾回收都是對那些在年輕代區域中不能被回收的物件進行回收。
同時結合觀察， 未進行FULL GC時，系統的CPU使用正常，但每次在FULL GC期間，系統CPU都在高位，說明CPU高與FULL GC垃圾回收有關，而FULL GC垃圾回收則是類似上圖中的佔用JVM記憶體較多的大物件。


Oslash;
首先解決執行環境的問題

針對以上記憶體溢位和CPU的問題，首先從執行環境中尋找其解決方案。
1、
升級WebLogic 8.1版本由SP3到SP6
2、
升級SUN jdk1.4.2 SR4到SUN jdk 1.4.2 SR19
//備註：在JDK每一個新版本都解決了這前版本許多的BUG，其中包含由JDK本身而引起的的JVM Crash、Thread Lock、CPU High等關鍵問題。
經過以上處理及JDK執行引數的調整後，對業務進行了壓力測試，當單節點併發使用者在80個以上同時執行了20多分鐘，資料庫的CPU達到100%時，而且WebLogic程式佔用CPU情況較正常，但越到最後，CPU使用情況就比較糟糕了，但最終未出現當機情況，此時觀察GC垃圾回收日誌，主要表現為FULL GC頻繁。
記憶體洩漏.GIF (13.2 KB)
下載次數:5
2010-2-21 18:29




http://bbs.weblogicfans.net/attachments/month_1002/1002211829e93467e885f679bf.gif
本帖最後由 chaowang 於 2010-2-21 19:01 編輯

再次處理環境外的問題
根據分析FULL GC頻繁的原因主要表現為大物件不能被回收，出現記憶體溢位，如附圖中的狀況。

記憶體溢位問題是目前應用伺服器當機的普通表現，其徹底解決辦法，也只能修改程式，調整相關引數只能起到緩解的作用。

根據多次觀察及分析GC日誌，根據目前32位環境的情況，目前JVM引數配置如下：


[*]-XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:+PrintGCApplicationStoppedTime
[*]-XX:+PrintGCApplicationConcurrentTime -Xms768m -Xmx1024m -XX:NewSize=512m -XX:MaxNewSize=512m
[*]-XX:NewRatio=2 -XX:SurvivorRatio=4 -XX:PermSize=128m -XX:MaxPermSize=256m -XX:MaxTenuringThreshold=20 -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:ParallelGCThreads=13 -XX:+CMSPermGenSweepingEnabled -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection
[*]-XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled

複製程式碼
根據春節期間連續9天未當機的執行情況分析，結果如下：

9天的普通GC垃圾回收共計29,136次，平均間隔時間為23.4秒進行一次，每次普通GC垃圾回收時間平均為0.7秒；
9天的FULL GC垃圾回收共計2,313，平均間隔時間為2.2秒進行一次，每次FULL GC垃圾回收時間平均為1.3秒，這個還是比較嚴重；

根據結果分析，雖然透過調整使目前環境相比之前的環境會穩定一點，但根本的問題還是存在。

Number of Full Garbage Collections : 2,313
Number of Minor Garbage Collections : 29,136
Average Full Garbage Collection interval : 2,268 milliseconds
Average Minor Garbage Collection interval : 23,408 milliseconds
Average Full Garbage Collection duration : 1,324 milliseconds
Average Minor Garbage Collection duration : 733 milliseconds

處理結果
根據本次的處理，保障了XXXX業務系統在春節期間不當機的正常執行。

經過多次分析及跟蹤，當機問題主要原因是因為程式中存在記憶體洩漏問題，而洩漏位置主要是XXXXX這個頁面訪問。

建議
1、  建議開發商修改程式XXXXX並。 [/quote]