注：在下面做的介紹都是以Weblogic8.1爲例的，其它版本的Weblogic可能會有些許不同。
1) 設置JAVA參數；
a) 編輯Weblogic Server啓動腳本文件；
BEA_HOME/user_projects/domains/domain-name/startWebLogic.cmd(startWebLogic.sh on Unix)
BEA_HOME/user_projects/domains/domain-name/startManagedWebLogic.cmd(startManagedWebLogic.sh on Unix) --這個是做集羣的時候用的
b) 編輯set JAVA_OPTIONS命令，如：set JAVA_OPTIONS=-Xms256m –Xmx256m；
（在UNIX下把MEM_ARGS="-Xms1024m -Xmx1024m -Xmn128m"加到上述兩個.sh文件中即可）
c) 保存，重啓即可。
注：在WebLogic中，爲了獲得更好的性能，BEA公司推薦最小Java堆等於最大Java堆。
（這個偶們的設置都是1024M的，反正偶們內存大大的4G呢）
2) 開發模式 vs. 產品模式；
開發模式和產品模式的一些參數的默認值不同，可能會對性能造成影響，下面是對性能有影響的參數列表：
| 參數 | 開發模式默認值 | 產品模式默認值 |
| Execute Queue: Thread Count | 15 threads | 25 threads |
| JDBC Connection Pool: MaxCapacity | 15 connnections | 25 connections |
通過啓動管理控制檯，在域（如：mydomain）> 配置 > 常規選擇產品模式。
（這個在創建weblogic的domain的時候是有選擇的，選擇“產品”模式就可以了，如果後期需要修改，可以按照上面的方法修改）
3) 儘量開啓本地I/O；
通過啓動管理控制檯，在域（如：mydomain）> 服務器 > server實例（如：myserver）> 配置 > 調整選擇啓用本地I/O。
注：此值也可通過手動的修改config.xml配置文件。
（這個沒有試驗過，不曉得有什麼效果和好處，知道的告訴偶下下。）
4) 調優執行隊列線程；
a) 修改默認執行線程數
在這裏，執行隊列的線程數表示執行隊列能夠同時執行的操作的數量。但此值不是設的越大越好，應該恰到好處的去設置它，太小了，執行隊列中將會積累很多待處理的任務，太大了，則會消耗大量的系統資源從而影響整體的性能。在產品模式下默認爲25個執行線程。
（點：一般來說，其上限是每個CPU對應50個線程，其按照CPU個數線性增長.）
爲了設置理想的執行隊列的線程數，我們可以啓動管理控制檯，在域（如：mydomain）> 服務器 > server實例（如：myserver）> 監視 > 性能中監控最大負載時執行隊列的吞吐量和隊列中的等待請求數，據此確定理想的數值。
理想的默認執行線程數是由多方面的因素決定的，比如機器CPU性能、總體體系架構、I/O、操作系統的進程調度機制、JVM的線程調度機制。隨着CPU個數的增加，WebLogic可以近乎線性地提高線程數。線程數越多，花費在線程切換的時間也就越多；線程數越小，CPU可能無法得到充分的利用。爲獲取一個理想的線程數，需要經過反覆的測試。在測試中，可以以25*CPU個數爲基準進行調整。當空閒線程較少，CPU利用率較低時，可以適當增加線程數的大小（每五個遞增）。對於PC Server和Windows 2000，則最好每個CPU小於50個線程，以CPU利用率爲90%左右爲最佳。
通過啓動管理控制檯，在域（如：mydomain）> 服務器 > server實例（如：myserver）> Execute Queue > weblogic.kernel.Defalt > 配置中修改線程計數。
b) 設定執行隊列的溢出條件；
Weblogic Server提供給默認的執行隊列或用戶自定義的執行隊列自定義溢出條件的功能，當滿足此溢出條件時，服務器改變其狀態爲“警告”狀態，並且額外的再分配一些線程去處理在隊列中的請求，而達到降低隊列長度的目的。
通過啓動管理控制檯，在域（如：mydomain）> 服務器 > server實例（如：myserver）> Execute Queue > weblogic.kernel.Defalt > 配置下面幾項：
●隊列長度：此值表示執行隊列中可容納的最大請求數，默認值是65536，最後不要手動改變此值。
●隊列長度閾值百分比：此值表示溢出條件，在此服務器指出隊列溢出之前可以達到的隊列長度大小的百分比。
●線程數增加：當檢測到溢出條件時，將增加到執行隊列中的線程數量。如果CPU和內存不是足夠的高，儘量不要改變默認值“0”。因爲Weblogic一旦增加後不會自動縮減，雖然最終可能確實起到了降低請求的作用，但在將來的運行中將影響程序的性能。
●最大線程數：爲了防止創建過多的線程數量，可以通過設定最大的線程數進行控制。
在實際的應用場景中，應根據具體情況適當的調整以上參數。
c) 設定執行隊列監測行爲
Weblogic Server能夠自動監測到當一個執行線程變爲“阻塞”。變爲“阻塞”狀態的執行線程將無法完成當前的工作，也無法再執行新請求。如果執行隊列中的所有執行線程都變爲“阻塞”狀態，Weblogic server可能改變狀態爲“警告”或“嚴重”狀態。如果Weblogic server變爲“嚴重”狀態，可以通過Node Manager來自動關閉此服務器並重新啓動它。具體請參考：Node Manager Capabilities文檔。
通過啓動管理控制檯，在域（如：mydomain）> 服務器 > server實例（如：myserver）>配置 > 調整下可配置下面幾項：
●阻塞線程最長時間：在此服務器將線程診斷爲阻塞線程之前，線程必須連續工作的時間長度(秒)。默認情況下，WebLogic Server 認爲線程在連續工作 600 秒後成爲阻塞線程。
●阻塞線程計時器間隔：WebLogic Server 定期掃描線程以查看它們是否已經連續工作了 "阻塞線程最長時間" 字段中指定的時間長度的間隔時間(秒)。默認情況下，WebLogic Server 將此時間間隔設置爲 600 秒。
5) 調優TCP連接緩存數；
WebLogic Server用Accept Backlog參數規定服務器向操作系統請求的隊列大小，默認值爲50。當系統重載負荷時,這個值可能過小,日誌中報Connection Refused,導致有效連接請求遭到拒絕,此時可以提高Accept Backlog 25%直到連接拒絕錯誤消失。對於Portal類型的應用,默認值往往是不夠的。
Login Timeout和SSL Login Timeout參數表示普通連接和SSL連接的超時時間,如果客戶連接被服務器中斷或者SSL容量大,可以嘗試增加該值。
通過啓動管理控制檯，在域（如：mydomain）> 服務器 > server實例（如：myserver）>配置 > 調整下可配置“接受預備連接”。
6) 改變Java編譯器；
標準的Java編譯器是javac，但編譯JSP servlets速度太慢，爲了提高編譯速度，可以使用sj或jikes編譯器取代javac編譯器。下面說說更改Java編譯器：
通過啓動管理控制檯，在域（如：mydomain）> 服務器 > server實例（如：myserver）>配置 > 常規下改變Java 編譯器，默認爲javac。輸入完整路徑，如：c:/visualcafe31/bin/sj.exe。然後打開高級選項，在預規劃到類路徑填寫編譯 Java 代碼時爲 Java 編譯器類路徑預規劃的選項，如：BEA_HOME/jdk141_02/jre/lib/rt.jar。
7) 使用Webogic Server集羣提高性能；
具體關於如何配置Weblogic集羣，我就不細說了。詳情可參考：Introduction to WebLogic Server Clustering。
8) Weblogic EJB調優
由於EJB2.0已經很少項目在用了，EJB3.0再成熟一點，我再補充這一部分吧！
9) JDBC應用調優
JDBC Connection Pool的調優受制於WebLogic Server線程數的設置和數據庫進程數,遊標的大小。通常我們在一個線程中使用一個連接,所以連接數並不是越多越好,爲避免兩邊的資源消耗，建議設置連接池的最大值等於或者略小於線程數。同時爲了減少新建連接的開銷,將最小值和最大值設爲一致。
增加Statement Cache Size對於大量使用PreparedStatement對象的應用程序很有幫助,WebLogic能夠爲每一個連接緩存這些對象,此值默認爲10。在保證數據庫遊標大小足夠的前提下,可以根據需要提高Statement Cache Size。比如當你設置連接數爲25,Cache Size爲10時,數據庫可能需要打開25*10=250個遊標。不幸的是,當遇到與PreparedStatement Cache有關的應用程序錯誤時,你需要將Cache Size設置爲0。
儘管JDBC Connection Pool提供了很多高級參數,在開發模式下比較有用,但大部分在生產環境下不需調整。這裏建議最好不要設置測試表, 同時Test Reserved Connections和Test Released Connections也無需勾上。 當然如果你的數據庫不穩定,時斷時續,你就可能需要上述的參數打開。
最後提一下驅動程序類型的選擇,以Oracle爲例,Oracle提供thin驅動和oci驅動,從性能上來講,oci驅動強於thin驅動,特別是大數據量的操作。但在簡單的數據庫操作中,性能相差不大,隨着thin驅動的不斷改進,這一弱勢將得到彌補。而thin驅動的移植性明顯強於oci驅動。所以在通常情況下建議使用thin驅動。而最新驅動器由於WebLogic server/bin目錄下的類包可能不是最新的,請以Oracle網站爲準: http://www.oracle.com/technology/software/tech/java/sqlj_jdbc/htdocs/jdbc9201.html。
10) JSP調優
設置jsp-param pageCheckSeconds=-1；
設置serlet-reload-check=-1或ServletReloadCheckSecs=-1；
設置jsp-param precompile=true，關閉JSP預編譯選項。
一個牛人給出的參考：
系統的線程池配置考慮以下因素：
1， 機器的計算能力；
2， 子系統每個線程的計算複雜性；
3， 整個系統的均衡性。
因此，建議設定一個標準範圍，例如（舉例說明，具體數值根據情況斟酌）：
機型：DL380G4/2*3G/4G，線程池大小範圍：80－120（無特殊情況一般設爲100）；
機型：DL380G5/2*2G/4G，線程池大小範圍：100－120（無特殊情況一般設爲110）；
機型：BL460C/2*3G/4G，線程池大小範圍：100－120（無特殊情況一般設爲110）；
Post by iceskysl on 2007, September 18, 11:50 AM #1
系統文件描述符數目不足
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 來動態更改進程的文件描述符的限制
Post by iceskysl on 2007, September 18, 11:55 AM #2
系統內存不足
JVM的heap區大小
通過java命令行中的-Xms,-Xmx指定，建議最小值和最大值設成一樣
可以通過weblogic console上server/monitor/performance來觀察其使用情況
建議生產系統最少256M，一般情況下可以設置爲系統剩餘物理內存的80％
Post by iceskysl on 2007, September 18, 11:57 AM #3
failureException: Error initializing Embedded LDAP Server - with nested exception: [java.lang.ClassCastException] java.lang.ClassCastException at weblogic.ldap.EmbeddedLDAP.initialize(EmbeddedLDAP.java:266)
改權限chown -R weblogic.weblogic /home/webogic
Post by iceskysl on 2007, September 18, 4:37 PM #4
修改文件句柄數：
1、修改/etc/security/limits.conf，需要root權限
vi /etc/security/limits.conf
# 確認包含下面的內容：
* soft nofile 8192
* hard nofile 8192
修改後，su到目標用戶，用ulimit –Hn和ulimit –Sn確認修改已生效
2、修改startManagedWebLogic.sh，找到resetFD那行，註釋掉。然後在腳本最後啓動JAVA進程的前面加上下面的內容，檢查系統文件句柄數是否修改：
echo
echo "-----------------------------------------------"
echo "Begin to check the file descriptor limit"
fd=`ulimit -n`
if [ $fd -lt 8192 ];
then
echo "Fatal Error!"
echo "The file descriptor limit is only '"$fd"'!"
echo "Please make it more than 8192!"
exit
fi
echo "OK, the file descriptor limit is" $fd
echo "-----------------------------------------------"
echo
echo
Post by iceskysl on 2007, September 18, 5:26 PM #5
查看文件句柄數：
/usr/sbin/lsof -n|awk '{print $2}'|sort|uniq -c |sort -nr|more
Post by iceskysl on 2007, September 20, 10:53 AM #6
我遇到的weblogic運行600秒超時主要有兩個原因：
1）SQL語句運行時線程阻塞
2）out.println語句運行時線程阻塞
第一種問題的解決辦法，編寫一個java桌面應用，測試運行的SQL語句是否可以正常運行，並返還正確結果。若無法正常運行，就需要通過視圖或其他的方式調整和優化SQL語句。
這裏需要注意：數據庫的不同版本可能需要相應版本的數據庫驅動。SQL語句不能正常運行，通常都是由驅動引起的。
第二種情況的解決辦法，weblogic或其他的中間件產品，服務端大多都會使用緩衝發送數據機制，當數據量大的時候會分批發送出去，若數據中出現過多的回車（/n或直接的回車）就會有一定的機率出線線程阻塞的情況，解決辦法就是消除回車符，儘量使輸出的數據是連續的字符流。
Post by iceskysl on 2007, September 22, 9:39 PM #7
分析線程堆棧：
http://bbs.sinoweb.com.cn/archiver/tid-405.html
Post by iceskysl on 2007, September 23, 2:13 AM #8
http://www.cntesting.com/portal/html/testing-technique/load-test/20070509/178.html
Post by iceskysl on 2007, September 23, 2:25 AM #9
最近生產環境下的系統經常出現以下的錯誤提示，
####<2007-7-2 下午04時07分20秒 CST> <Error> <WebLogicServer> <gis> <portalServer> <weblogic.health.CoreHealthMonitor> <<WLS Kernel>> <> <BEA-000337> <ExecuteThread: '5' for queue: 'default' has been busy for "1,165" seconds working on the request "Http Request: /tzzmWeb/saye/regie/census/customertoMtn/custcheckout.do", which is more than the configured time (StuckThreadMaxTime) of "600" seconds.>
該問題是由於處理custcheckout.do請求超時引起的，系統配置的處理時間是600s，但是該線程處理了1165s後，仍然沒將請求釋放，所以報了這個錯誤。如果發送該請求較多，很有可能會導致weblogic的線程阻塞，嚴重會引起weblogic掛起現象。
可以通過以下幾種方法解決：
1）修改StuckThreadMaxTime參數，將默認的600s改成1200s，或者其它適合的值。
2）增大線程數，防止線程阻塞問題。
3）優化程序，減少處理時間。
點評：還可能是網絡的問題導致的～
Post by iceskysl on 2007, September 23, 12:12 PM #10
JVM內存的設置的原理
http://hi.baidu.com/haoyan665/blog/item/e148c45001115f6084352422.html