weblogic調優
本文由weblogic中國論壇http://www.weblogicfans.net提供技術支持。大家有關於對weblogic調優的問題，已經weblogic性能問題，請到weblogic論壇http://www.weblogicfans.net 發表自己的觀點。weblogicfans是由原BEA的dev2dev論壇延續而來。其目的就是為中國廣大weblogic工作者創建一個良好的交流平台。
調優方案
WEBLOGIC SERVER Hang產生的原因一般為：
系統記憶體不足
系統cpu忙
系統檔案描述符數目不足
執行緒死鎖
JVM有GC方面的bug
對於一些特定的情況可以使用truss命令跟蹤系統調用來進行分析
系統記憶體不足
出現OutOfMemoryError或是觀察到記憶體吃緊
作業系統本身的剩餘記憶體
通過top或是vmstat觀察
作業系統的swap區
Swap區太小可能導致編譯jsp時報“Not enough space”的錯
作業系統kernel參數中maxdsiz的大小
如果觀測到資料庫連線池里的連線泄漏，極可能是記憶體泄漏的先兆
系統記憶體不足
JVM的heap區大小
通過java命令行中的-XMS,-Xmx指定，建議最小值和最大值設成一樣
可以通過weblogic console上server/monitor/performance來觀察其使用情況
建議生產系統最少256M，一般情況下可以設定為系統剩餘物理記憶體的80％
Heap size太大在一些jvm上會有問題
對於sun和hp的jvm，permanent size太小也會出OutOfMemoryError
在java命令行上加-XX:MaxPermSize=128m
系統記憶體不足
儘量減少記憶體消耗
Session中不要放大的數據，並儘量在不再需要的時候remove掉；如果可以調整session timeout到較小的值
避免在J2EE server端套用裡邊調用awt/swing作圖
調整ejb的cache/pool設定
系統記憶體不足
記憶體泄漏
可以通過weblogic console來觀察jvm的heap memory使用情況來獲知是否有記憶體泄漏情況
採用第三方輔助工具來獲取更詳細信息
jprobe/OptimizeIt
有可能是weblogic的bug，但絕大部分情況是由用戶的套用引起的
最常見的代碼問題是資料庫連線沒正常關閉
比較好的寫法是：
Connection conn = null;
Statement stmt = null;
ResultSet RSet= null;
try
{
conn = getConnection()…
}
catch(SQLException sqle)
{
}
finally
{
try{rset.close();}catch(Exception e){}
try{stmt.close();}catch(Exception e){}
try{conn.close();}catch(Exception e){}
}
系統cpu忙
如果用戶訪問量很大，cpu占用很高（user態）並不是異常
如果是kernel態很多，需要OS廠商調整作業系統
採用top找到占用cpu很多的進程
如果是非weblogic進程，應該考慮將其移到另外的server上運行
如果是運行weblogic的java進程，通過做thread dump（詳細信息後邊會介紹到）來確認是那段代碼導致了這么高的cpu使用（也有可能是os/jvm本身不正常）
系統檔案描述符數目不足
Log中有“too many open files”的錯誤
表示達到了系統對一個進程能同時打開的檔案數的限制
ulimit –a –H 可以查看當前限制
ulimit –n number可以來更改當前環境的設定，建議至少設到4096
Solaris上可以通過/usr/proc/bin/pfiles pid來查看指定進程的限制和當前使用的file descriptor數目
Solaris上root用戶可以通過/usr/proc/bin/plimit -n soft,hard pid 來動態更改進程的檔案描述符的限制
執行緒死鎖
對於原因不明的hang或是回響慢，最根本的方法就是獲取thread dump信息
對於windows系統，在運行java的視窗按Ctrl＋Break
對於unix系統，首先用ps找到運行weblogic的java進程的pid，然後執行kill –3 pid
JVM將負責將所有java進程的狀態、執行堆疊dump到其標準輸出
為了方便獲取thread dump信息，在weblogic啟動的時候，最好將其標準輸出重定向到一個檔案
為了反映執行緒狀態的動態變化，需要接連多次做thread dump，每次間隔10-20s
執行緒死鎖
對於thread dump信息，主要關注的是執行緒的狀態和其執行堆疊
執行緒的狀態一般為三類
Runnable（R）：當前可以運行的執行緒
Waiting on monitor（CW）：執行緒主動wait
Waiting for monitor entry（MW）：執行緒等鎖
一般關注的都是第一和第三種狀態的執行緒
Cpu很忙則關注runnable的執行緒
Cpu閒則關注waiting for monitor entry的執行緒
一種典型的死鎖是由於在server端套用（比如servlet）中請求由同一weblogic實例serve的資源
解決辦法就是將該servlet放到另外的執行佇列里去執行
JVM有GC方面的bug
打開jvm的gc log
在java命令行上加上-verbose:gc
GC的log輸出在java進程的標準輸出里
在hp的jvm上，可以通過在java命令行上加
-Xverbosegc:file=gcfilename來將gc log寫到指定的檔案
其輸出類似：
[GC 15639K->13700K(65280K), 0.0068439 SECS]
調整jvm的記憶體設定和gc算法
升級jvm或是os patch
mit –n number可以來更改當前環境的設定，建議至少設到4096
Solaris上可以通過/usr/proc/bin/pfiles pid來查看指定進程的限制和當前使用的file descriptor數目
Solaris上root用戶可以通過/usr/proc/bin/plimit -n soft,hard pid 來動態更改進程的檔案描述符的限制
執行緒死鎖
對於原因不明的hang或是回響慢，最根本的方法就是獲取thread dump信息
對於windows系統，在運行java的視窗按Ctrl＋Break
對於unix系統，首先用ps找到運行weblogic的java進程的pid，然後執行kill –3 pid
JVM將負責將所有java進程的
