中間件WebLogic/Tuxedo/GoldenGate的排錯與優(yōu)化（獲獎名單已公布）

Mrbaifly

很好，感謝戴老師為我們解答疑惑，大力支持一下！

zhaopingzi

請問樓主OOM級別級別如何處理？

dream0110

好活動，支持！

chenyx

好活動,支持一下.對中間件不熟悉

三人行必有吾師

回復(fù) 22# zhaopingzi

謝謝提問，這個問題涵蓋的范圍有些大，所以在《WebLogic實戰(zhàn)》連續(xù)的第16/17/18章都是相關(guān)內(nèi)容。

總體而言，幾個注意要點：
1. 最簡單的，JVM本身開的空間即不夠，可以調(diào)節(jié)起始值-Xms和最大值-Xmx；32位的經(jīng)常還需要調(diào)節(jié)操作系統(tǒng)參數(shù)才能將分配給JVM的內(nèi)存擴(kuò)上去；不過這里面有些雜七雜八的小技巧：
(1) 在一般的JDK實現(xiàn)中，在生產(chǎn)環(huán)境多將兩個值設(shè)成一樣以提高性能；
(2) 但在IBM的AIX生產(chǎn)環(huán)境下，反而需要設(shè)成不一樣來優(yōu)化內(nèi)存碎片，因為它的實現(xiàn)不是基于標(biāo)準(zhǔn)的代的概念，而是P簇/K簇這樣的思路；
(3) 在HP的UX環(huán)境下，通常隨著這兩個參數(shù)不同，會自適應(yīng)觸發(fā)出不同的進(jìn)程模式，所謂q3p,q4p等，可用最大Heap空間大小是變動的。

2. 另外，在大多數(shù)JDK實現(xiàn)中，一般會保留一個相關(guān)的各種Class的代碼段，通常所說的Permanent區(qū)域，也可能是這個不夠；因為它不參與垃圾回收，所以需要給出足夠的空間；

3. 再者，由于JVM顧名思義，是虛擬機，所以不會象硬件CPU一樣，有ALU，有AX/BX/PC等諸多寄存器和運算器，所以其映射為一個個Frame幀來模擬，如果Frame鏈的空間不夠，多半會體現(xiàn)在堆棧溢出上；

4. 當(dāng)然，最常見的還是內(nèi)存泄漏，需要捕獲內(nèi)存鏡像(多次最好)，比如JDK自帶的命令Jmap等，然后用工具分析，MAT/HA等，這個需要實際處理的經(jīng)驗，就象醫(yī)生看X光片一樣：
(1) 找內(nèi)存占用最大的幾個部分;
(2) 找內(nèi)存占用變化最大的幾個部分；

5. 還有比較隱藏比較深的，比如內(nèi)存碎片，雖然整個Heap的空余空間綽綽有余，但還是報內(nèi)存不夠，主要起因于空閑內(nèi)存空間不連續(xù)，就象以前硬盤小做磁盤整理時，星星點點的紅色區(qū)域無法移動一樣；

6. 此外，象JMS/EJB等，或者應(yīng)用上，大規(guī)模的對象申請和占用，都會容易觸發(fā)該類問題，在GIS系統(tǒng)，基于WLI/OSB的工作流和業(yè)務(wù)系統(tǒng)都容易碰到。

   

Bacon_Lee

好活動，支持啊~~

jqm2009

【常見的中間件調(diào)優(yōu)手段】
1、在什么情況下，我調(diào)整AdminServer的啟動參數(shù)能夠達(dá)到性能優(yōu)化的目的？比如說，當(dāng)AdminServer管理的節(jié)點服務(wù)器數(shù)很多？要部署的應(yīng)用很大？
2、當(dāng)我在console中，對某個節(jié)點服務(wù)器執(zhí)行shutdown操作時，節(jié)點遲遲不能被停掉，后臺log中會打出一些thread dump日志，這是什么原因？
3、我的環(huán)境是AdminServer通過node manager對節(jié)點服務(wù)器進(jìn)行管理，對應(yīng)后臺的.out為標(biāo)注輸出日志，如果節(jié)點服務(wù)器一直運行，該.out日志會持續(xù)不斷增大，如何對weblogic的日志進(jìn)行優(yōu)化？

三人行必有吾師

回復(fù) 27# jqm2009

謝謝，這些在書中相關(guān)章節(jié)部分都有涉及。

總體來看，貴方應(yīng)該采用的是多個WebLogic實例組合工作的模式，而不是單實例Standalone(即就一個單Admin Server，并在其上部署所有應(yīng)用)；這種情境下，業(yè)務(wù)主要跑在Managed Server上，Admin Server更偏向于管理功能和監(jiān)控接口。這時，對于Admin Server調(diào)優(yōu)的目標(biāo)要很明確，不是按照常規(guī)網(wǎng)路上的文章，所謂優(yōu)化線程，優(yōu)化連接池等等；而是要去優(yōu)化各服務(wù)器間的通訊和同步，防止Admin Server和各個Managed Server之間的阻滯，以及各個實例間同步的消耗；以前在極端情況下，真實的大型客戶系統(tǒng)，由于前面F5的分發(fā)紊亂，Sesssion來回復(fù)制和遷移，導(dǎo)致每個實例一半的CPU都耗在同步上了，整個系統(tǒng)響應(yīng)遲滯或不能正常快速登入；

可以：
(1) 給小的內(nèi)存和線程資源，避免過多的浪費和內(nèi)耗，畢竟不怎么跑業(yè)務(wù)；
(2) 采用Multicast，而不是Unicast，因為局域網(wǎng)上Multicast充份利用了以太網(wǎng)總線機制載波監(jiān)聽的特點，一組數(shù)據(jù)單點發(fā)布，其余各節(jié)點并行收到(IGMP隧道技術(shù)暫不在此討論之列)；用Unicast，其實就是個輪詢，內(nèi)部寫了個循環(huán)，點對點挨個通訊一遍；
(3) 如果都在防火墻后，可以關(guān)閉Server之間的加密，比如t3s協(xié)議，比如Server間證書校驗；
(4) 所有可以優(yōu)化RJVM通訊的地方；比如控制臺上關(guān)于協(xié)議那一頁的參數(shù)；

還有，應(yīng)用大小，對于從Admin Server發(fā)布到Managed Server的Stage模式，的確是會比較敏感；如果有條件，可以用non-stage或external-stage，否則光系統(tǒng)啟動就得半天，忙著拷數(shù)據(jù)啊。我記得以前有個大客戶，用Portal門戶，而且?guī)�文件和圖片上載功能的，發(fā)現(xiàn)系統(tǒng)越跑越慢，一年后啟動一次要半個小時；結(jié)果一跟蹤一看，歷史圖片文件都上N多了，啟動時一直不斷的從Admin Server在往Managed Server上發(fā)布呢

至于通過Node Manager，節(jié)點宕掉緩慢，一般有還在同步各Server間的狀態(tài)，包括JNDI信息的；還有就是這個Managed Server自己運行狀況出問題了，我估計那個Thread Dump是一些異常堆棧吧？需要看到這個，就比較明確了。一般而言，除非是主動觸發(fā)了Thread Dump，或者內(nèi)存方面的問題Managed Server掛掉了，JVM不會自己打出個完整的Thread Dump清單出來。如果真是down不下來，而其日志里又有完整的Thread Dump，很多情況下這個Managed Server已經(jīng)提前掛了，而其中OOM的比率又比較高。

至于日志文件，看來不是指WebLogic自己的Server日志和Domain日志，那兩個可以調(diào)節(jié)滾動機制的，比如按時間滾動，或者按大小滾動，保留多少個，等等。。。也可以調(diào)整日志輸出級別來調(diào)整日志輸出量的大��；應(yīng)該是指把標(biāo)準(zhǔn)錯誤，標(biāo)準(zhǔn)輸出到文件的輸出日志，通常寫法為"2>&1 1>xxx.out”，這個屬于操作系統(tǒng)層面管理的，比較好的做法是，寫個腳本定時備份和清理即可，比較簡單，用“>”清空；“>>”追加。

jqm2009

非常感謝您的解答。
我們的環(huán)境使用的是的JDK是jrockit-jdk1.6.0_20-R28.1.0-4.0.1，在啟動腳本中是這樣配置的MEM_ARGS="-Xms4096M -Xmx4096M -Xgc:gencon -Xns512M " ，不知道您推薦的怎樣的參數(shù)配置？

三人行必有吾師

回復(fù) 29# jqm2009

您好：謝謝！

如果僅就內(nèi)存參數(shù)的討論范圍而言，這個值用在一個Managed Server上可能是合適的，但如果用在一個沒有部署什么應(yīng)用的Admin Server上就實在是浪費了。。。因為那些參數(shù)里指定了初始最小和最大的Heap相等是4G；用了普通的分代并行算法，Nursery大小為512兆(其實就是Young區(qū))；

如果是個單純干凈的Admin Server，給1G甚至更小就足夠了，即-Xms1024M, -Xmx1024M