轉(zhuǎn)載： http://tanyankai.iteye.com/blog/570675
JBoss4瘦身
前言
這個(gè)建議主要是如果對(duì)JBossAS進(jìn)行調(diào)優(yōu)和瘦身的. 這個(gè)概念在多數(shù)情況是交叉的。當(dāng)通過(guò)瘦身減少閑置服務(wù)線程并不能帶來(lái)大的性能影響的時(shí)候，允許你使用較少的內(nèi)存和資源對(duì)其他性能方便進(jìn)行調(diào)整。當(dāng)然它可以縮短啟動(dòng)時(shí)間。而且，作為一般的安全觀念――移除你不使用的服務(wù)。我們將分開(kāi)兩個(gè)種類(lèi): 瘦身和調(diào)優(yōu). 首先我們使用默認(rèn)的配置并從那里開(kāi)始瘦身(對(duì)于clustering的話(huà)題，將在以后的wiki頁(yè)面進(jìn)行討論 ;-) ). 這個(gè)建議不牽扯開(kāi)發(fā)者和管理角色交叉調(diào)優(yōu)的區(qū)域開(kāi)發(fā)者和管理角色 (應(yīng)用程序調(diào)優(yōu)象cache大小一樣). 這主要是對(duì)于管理調(diào)優(yōu)的建議.
這建議將做技術(shù)上非J2EE平臺(tái)兼容(3.2.6無(wú)論如何不順從)的JBoss實(shí)例的有關(guān)的那些注意，象除去J2EE關(guān)鍵 服務(wù)的那樣將導(dǎo)致JBoss 失敗TCK。多數(shù)性能調(diào)優(yōu)/管理任務(wù)工作，在現(xiàn)實(shí)世界結(jié)構(gòu)里，在技術(shù)上屬于這個(gè)類(lèi)別。
假設(shè)你已經(jīng)復(fù)制server/default 文件夾并將它重新命名為server/slim.
調(diào)優(yōu)
Java Virtual Machine Java虛擬機(jī)
l 對(duì)于你的機(jī)器和內(nèi)存大小來(lái)調(diào)整VM垃圾收集或者調(diào)整 JDK 5 的垃圾收集
l 使用64位的機(jī)器和64位的VM，以便你能使用大的heap(堆)大小，通常比2－4GB的大。64位支持在所有最新的SPARC/Solaris 寄存器運(yùn)行Solaris 9 或者以后的版本是有效的, Itanium 使用 JDK 1.4, 或者在Linux x64 上使用JDK 5.
l 如果你不使用上面的最大32位heap空間(2-4 GB 的heap)，不要使用 –d64. 使用64位地址需要更多的內(nèi)存來(lái)做同樣的工作量，并且對(duì)于應(yīng)用程序不需要如此多的內(nèi)存來(lái)說(shuō)并不能提供更大優(yōu)勢(shì)。
l 除了避免額外小的heaps外還要避免額外大的heaps. (我們不能告訴你具備什么資格，因?yàn)樗Q于你正做什么). 這影響generational 垃圾收集和掃描heap的總的時(shí)間. 有效的調(diào)整一個(gè)小heap是困難的 (即使你的應(yīng)用程序僅僅需要使用200MB，如果你使用并行垃圾收集＋CMS，然后你將需要遠(yuǎn)高于512MB). 特大號(hào)的heaps為垃圾收集花費(fèi)不必要的時(shí)間掃描內(nèi)存。
l 避開(kāi) Sun 1.4 VM. JDK 5 主要是在垃圾收集方面非常的好.
l 使用 -server 參數(shù)除了使用其他-XX:ThreadStackSize=128k (Solaris) 或者 -Xss128k (其他任何平臺(tái)). 在Solaris 上 -Xss128k 什么也沒(méi)有做 (你只可以設(shè)置較大的線程棧大小). 這允許你每個(gè)線程通過(guò)使用較少的內(nèi)存達(dá)到創(chuàng)建更多線程的目的。but might result in blown stacks with extremely recursive code. 然而, 128k 棧 is still nothing to shake a stick at.
l 你真的需要明白恰當(dāng)?shù)?span>generational 垃圾收集調(diào)整和你真的已經(jīng)進(jìn)行了負(fù)載測(cè)試 (OpenSTA?, JMeter, 等等) 確認(rèn)是有把握的.
l 你確實(shí)將使用一個(gè)超過(guò)2個(gè)處理器的多核心機(jī)器，及使用不同的平行和并行垃圾收集選擇 (我們談及這先進(jìn)的JBoss訓(xùn)練暗示伏筆) 對(duì)于最大性能和高拉機(jī)回收吞吐量. 不過(guò),你確實(shí)需要理解怎么調(diào)整才能使得垃圾收集很好的工作。JDK 5大部分是自我調(diào)整.
l JDK 1.4的默認(rèn) NewSize? 不是好的猜想. 壞的經(jīng)驗(yàn)法則: < 20% 是一個(gè)好的 NewSize?. 20%以上的消費(fèi)是危險(xiǎn)的，這是JDK令人討厭的一個(gè)，能導(dǎo)致它psychotically運(yùn)行所有滿(mǎn)垃圾回收和從未 unsuspend 或者釋放出 足夠多的內(nèi)存. JDK 5 似乎沒(méi)有展示出這個(gè)bug，并且似乎已回升更理智的默認(rèn)值。
JBoss/Java on Linux
如果你正在運(yùn)行JBoss AS在Linux服務(wù)器上，你應(yīng)該看看這篇文章的作者： Andrew Oliver, Jboss事業(yè)部, Red Hat公司, 顧問(wèn) ，在 在Linux服務(wù)器上怎么優(yōu)化Jboss/Java
Tomcat
l 編輯你的server/slim/jbossweb-tomcat5?.sar/server.xml 文件
l 檢查你正在使用的連接器的XML文檔. 例如, HTTP 連接器:
<Connector port="8080" address="${jboss.bind.address}"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" redirectPort="8443" acceptCount="100"
connectionTimeout="20000" disableUploadTimeout="true"/>
l 你應(yīng)該有多于你最大預(yù)期25％(經(jīng)驗(yàn)法則)的線程(maxThreads)來(lái)處理負(fù)載(將來(lái)一次性的并發(fā)訪問(wèn))
l 你應(yīng)該有minSpareThreads 等于恰好比你正常負(fù)載多一點(diǎn)
l 你應(yīng)該有maxSpareThreads等于恰好比你峰值負(fù)載多一點(diǎn)
l minSpareThreads 意思是 "啟動(dòng)準(zhǔn)備就緒, 總是保持至少這些線程來(lái)等待處理"
l maxSpareThreads means "如果我們總是超過(guò)minSpareThreads那么總是保持 maxSpareThreads 來(lái)等待處理"
l 移除任何不需要的值和日志。如果你不用JBoss的安全，移除這個(gè)安全值 (見(jiàn)下面).
l Precompile(預(yù)編譯) JSPs. (這個(gè)內(nèi)置的編譯器非常的會(huì)，它可能對(duì)于小型站點(diǎn)不值得做.)
l 在你的sever/slim/jbossweb-tomcat50.sar/conf/web.xml 里關(guān)閉開(kāi)發(fā)（"development"）模式
RMI的遠(yuǎn)程調(diào)用
默認(rèn)情況下, JBoss為進(jìn)來(lái)的每個(gè)RMI請(qǐng)求創(chuàng)建一個(gè)新線程. 在一個(gè)大系統(tǒng)中這一般不是高效率的. 其次,它允許無(wú)限制的連接在性能或者通信峰值或者run-away 連接方面創(chuàng)建客戶(hù)端可能是危險(xiǎn)的。為了補(bǔ)救這個(gè)你應(yīng)該考慮轉(zhuǎn)向被集中的池請(qǐng)求.
編輯 server/slim/conf/standardjboss.xml
通過(guò)改變每個(gè)XML分段讀數(shù)把所有代理綁定改變成被集中的池請(qǐng)求：
<invoker-mbean>jboss:service=invoker,type=jrmp</invoker-mbean>
到
<invoker-mbean>jboss:service=invoker,type=pooled</invoker-mbean>
JBoss也有大部分無(wú)文件證明的PooledInvokerHA你可以試試。
Log4j
日志在性能方面也有重要的影響. 改變?nèi)罩炯?jí)別跟蹤能給JBossAS 帶來(lái)蠕蟲(chóng)一樣的速度。改變級(jí)別為 ERROR (或者WARN) 能引人注目的提升速度。
l 默認(rèn)情況下, JBoss的日志被打印到控制臺(tái)和server.log文件里并且它默認(rèn)使用的日志級(jí)別是 "INFO".
l 考慮不記錄到System.out (你也能仍舊想改變方向以抓取JVM 錯(cuò)誤)
l 考慮改變?nèi)罩镜募?jí)別為ERROR. 觀察JBoss的log4j配置文件的變化，你可以在其運(yùn)行的時(shí)候改變這個(gè)配置。
l 給你的java class層次增加一個(gè)類(lèi)別過(guò)濾器.
關(guān)掉打印到控制臺(tái)的日志（console logging）:
l 編輯 server/slim/conf/log4j.xml
l 改變下面的XML 片段:
<root>
<appender-ref ref=CONSOLE"/>
<appender-ref ref="FILE"/>
</root>
修改成
<root>
<appender-ref ref="FILE"/>
</root>
l 然后你可以刪除此片段:
<appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender">
<errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
<param name="Target" value="System.out"/>
<param name="Threshold" value="INFO"/>
<layout class="org.apache.log4j.PatternLayout">
<!-- The default pattern: Date Priority [Category] Message\n -->
<param name="ConversionPattern" value="%d{ABSOLUTE} %-5p [%c{1}] %m%n"/>
</layout>
</appender>
改變?nèi)罩镜募?jí)別:
l 編輯 server/slim/conf/log4j.xml
l 移除/注釋 這些XML 片段:
<category name="org.apache">
<priority value="INFO"/>
</category>
<!—極限 org.jgroups 類(lèi)別為INFO -->
<category name="org.jgroups">
<priority value="INFO"/>
</category>
l 改變這個(gè)XML片段以改變r(jià)oot類(lèi)別:
<root>
<appender-ref ref="CONSOLE"/> <!—你可能在前面已經(jīng)移除這個(gè)-->
<appender-ref ref="FILE"/>
</root>
看上去像這樣
<root>
<priority value="ERROR" />
<appender-ref ref="CONSOLE"/> <!--你可能在前面已經(jīng)移除這個(gè)-->
<appender-ref ref="FILE"/>
</root>
另外，如果你使用了hibernate的話(huà)：
l 編輯 server/slim/conf/log4j.xml
l 增加如下XML 片段
<category name="org.hibernate" >
<priority value="INFO" />
</category>
最后, 在log4j中也許是最重要的事情，在你擁有的 class 結(jié)構(gòu)上確保你的極限的日志級(jí)別. 假設(shè)你正在使用的log4j打算不向System.out打印任何東西. 這將大大的降低log4j的額外開(kāi)銷(xiāo)，并且允許你完全享受益處，像如果調(diào)用(log.isDebugEnabled())....如果你那么做，那么你的代碼中的所有日志都將通過(guò)appender進(jìn)行格式化, 這個(gè)threshold 在appender將被從日志消息中去除出去. 它能產(chǎn)生大量的垃圾信息。假設(shè)你的java package 以“a.b”開(kāi)始的話(huà), 在log4j.xml增加一些像這樣的信息:
<!--極限a.b 類(lèi)別為INFO -->
<category name="a.b">
<priority value="INFO"/>
</category>
這個(gè)可以增加到你在org.apache 和 org.jboss (見(jiàn)上文)中找到過(guò)濾類(lèi)別的同一區(qū)域.
部署掃描器（Deployment Scanner ）
l 部署掃描器每隔5秒掃描一次，在比較慢的文件系統(tǒng)上尤其吃周期 (*cough* NTFS *cough*).
l 見(jiàn)下面的瘦身stuff on ，怎么調(diào)整秒數(shù)以至于它發(fā)生的不那么頻繁或者不全部發(fā)生。
無(wú)狀態(tài)會(huì)話(huà)Beans（Stateless Session Beans ）
l EJB 1.x-2.x 無(wú)狀態(tài)會(huì)話(huà)beans operate with an ill-advised pooling model (required by the specification). 如果你find你需要考慮設(shè)置比默認(rèn)（10）實(shí)例要多的最小線程池的大小:
編輯 server/slim/conf/standardjboss.xml, 向下滾動(dòng):
<container-configuration>
<container-name>Standard Stateless SessionBean</container-name>
<call-logging>false</call-logging>
<invoker-proxy-binding-name>stateless-rmi-invoker</invoker-proxy-binding-name>
<container-interceptors>
并找到:
<container-pool-conf>
<MaximumSize>100</MaximumSize>
</container-pool-conf>
</container-configuration>
改變它為:
<container-pool-conf>
<MinimumSize>100</MinimumSize>
<MaximumSize>100</MaximumSize>
<strictMaximumSize/>
<strictTimeout>30000</strictTimeout>
</container-pool-conf>
</container-configuration>
在很大程度上一種服務(wù)器環(huán)境中不希望這些池增長(zhǎng)和縮減(因?yàn)樗鼘?dǎo)致內(nèi)存碎片，不如潛在的堆使用). 從性能上來(lái)說(shuō), nuber要足夠的大以提供保證你的所有請(qǐng)求不阻塞的服務(wù)。
CMP 調(diào)整
l 讀這個(gè)鏈接: [url]http://www.artima.com/forums/flat.jsp?forum=141&thread=24532[/url]
l 和這個(gè)鏈接: [url]http://www.onjava.com/pub/a/onjava/2003/05/28/jboss_optimization.html[/url]
l 現(xiàn)在ditch CMP 和使用JBossHibernate 代替
連接池（Connection Pools）
l 不要使用XA版本，除非你真的知道你需要使用它. XA連接的性能不好.
l 與其在可用的地方利用數(shù)據(jù)庫(kù)特定的"ping"支持"check-connection"(檢查連接)，或者利用數(shù)據(jù)庫(kù)特定驅(qū)動(dòng)的fail-over支持倒不如從不checking connections. (記住并非所有的優(yōu)化選項(xiàng)都適合你的環(huán)境，我們正在討論的是最佳情況) 。