weblogic內存調優

JVM內存原理,weblogic內存的調優 

一.JVM內存的設置的原理

默認的java虛擬機的大小比較小,在對大數據進行處理時java就會報錯:java.lang.OutOfMemoryError。設置jvm內存的方法,對於單獨的.class,可以用下面的方法對Test運行時的jvm內存進行設置。

java-Xms64m -Xmx256m Test

-Xms是設置內存初始化的大小

-Xmx是設置最大能夠使用內存的大小(最好不要超過物理內存大小)
在weblogic中,可以在startweblogic.cmd中對每個domain虛擬內存的大小進行設置,默認的設置是在commEnv.cmd裏面。

-vmargs 

-Xms128M

-Xmx512M 

-XX:PermSize=64M 

-XX:MaxPermSize=128M

下面是這幾個設置的一些背景知識:

·  堆(Heap)和非堆(Non-heap)內存
按照官方的說法:“Java 虛擬機具有一個堆,堆是運行時數據區域,所有類實例和數組的內存均

從此處分配。堆是在 Java 虛擬機啓動時創建的。”“在JVM中堆之外的內存稱爲非堆內存(Non-heap

 memory)”。可以看出JVM主要管理兩種類型的內存:堆和非堆。簡單來說堆就是Java代碼可及

的內存,是留給開發人員使用的;非堆就是JVM留給 自己用的,所以方法區、JVM內部處理或優

化所需的內存(如JIT編譯後的代碼緩存)、每個類結構(如運行時常數池、字段和方法數據)以及方法和

構造方法 的代碼都在非堆內存中。

·  堆內存分配

JVM初始分配的內存由-Xms指定,默認是物理內存的1/64;JVM最大分配的內存由-Xmx指定,默認是物理內存的1/4。默認空餘堆內存小於40%時,JVM就會增大堆直到-Xmx的最大限制;空餘堆內存大於70%時, JVM會減少堆直到-Xms的最小限制。因此服務器一般設置-Xms、-Xmx相等以避免在每次GC 後調整堆的大小。

·  非堆內存分配
JVM使用-XX:PermSize設置非堆內存初始值,默認是物理內存的1/64;由XX:MaxPermSize

設置最大非堆內存的大小,默認是物理內存的1/4。

·  JVM內存限制(最大值)
首先JVM內存首先受限於實際的最大物理內存,假設物理內存無限大的話,JVM內存的最大

值跟操作系統有很大的關係。簡單的說就32位處理器雖然可控內存空間有4GB,但是具體的操作系

統會給一個限制,這個限制一般是 2GB-3GB(一般來說Windows系統下爲1.5G-2G,Linux系統

下爲2G-3G),而64bit以上的處理器就不會有限制了JVM內存的調優

1.Heap設定與垃圾回收Java Heap分爲3個區,Young,Old和Permanent。Young保存剛實例化的對象。當該區被填滿時,GC會將對象移到Old區。Permanent區則負責保存反射對象,本文不討論該區。JVM的Heap分配可以使用-X參數設定,

 

-Xms

初始Heap大小

-Xmx

java  heap最大值

-Xmn

young  generation的heap大小

 

JVM有2個GC線程。第一個線程負責回收Heap的Young區。第二個線程在Heap不足時,遍歷Heap,將Young 區升級爲Older區。Older區的大小等於-Xmx減去-Xmn,不能將-Xms的值設的過大,因爲第二個線程被迫運行會降低JVM的性能。

爲什麼一些程序頻繁發生GC?有如下原因:

1、       程序內調用了System.gc()或Runtime.gc()。

2、       一些中間件軟件調用自己的GC方法,此時需要設置參數禁止這些GC。

3、       Java的Heap太小,一般默認的Heap值都很小。

4、       頻繁實例化對象,Release對象。此時儘量保存並重用對象,例如使用StringBuffer()和String()。

         如果你發現每次GC後,Heap的剩餘空間會是總空間的50%,這表示你的Heap處於健康狀態。許多Server端的Java程序每次GC後最好能有65%的剩餘空間。經驗之談:

1.Server端JVM最好將-Xms和-Xmx設爲相同值。爲了優化GC,最好讓-Xmn值約等於-Xmx的1/3[2]。

2.一個GUI程序最好是每10到20秒間運行一次GC,每次在半秒之內完成[2]。

注意:

1.增加Heap的大小雖然會降低GC的頻率,但也增加了每次GC的時間。並且GC運行時,所有的用戶線程將暫停,也就是GC期間,Java應用程序不做任何工作。

2.Heap大小並不決定進程的內存使用量。進程的內存使用量要大於-Xmx定義的值,因爲Java爲其他任務分配內存,例如每個線程的Stack等。

2.Stack的設定

每個線程都有他自己的Stack。

 

-Xss

每個線程的Stack大小

 

Stack的大小限制着線程的數量。如果Stack過大就好導致內存溢漏。-Xss參數決定Stack大小,例如-Xss1024K。如果Stack太小,也會導致Stack溢漏。

3.硬件環境

硬件環境也影響GC的效率,例如機器的種類,內存,swap空間,和CPU的數量。

如果你的程序需要頻繁創建很多transient對象,會導致JVM頻繁GC。這種情況你可以增加機器的內存,來減少Swap空間的使用[2]。

4.4種GC

第一種爲單線程GC,也是默認的GC。,該GC適用於單CPU機器。

第二種爲Throughput GC,是多線程的GC,適用於多CPU,使用大量線程的程序。第二種GC與第一種GC相似,不同在於GC在收集Young區是多線程的,但在Old區和第一種一樣,仍然採用單線程。-XX:+UseParallelGC參數啓動該GC。

第三種爲Concurrent Low Pause GC,類似於第一種,適用於多CPU,並要求縮短因GC造成程序停滯的時間。這種GC可以在Old區的回收同時,運行應用程序。-XX:+UseConcMarkSweepGC參數啓動該GC。

第四種爲Incremental Low Pause GC,適用於要求縮短因GC造成程序停滯的時間。這種GC可以在Young區回收的同時,回收一部分Old區對象。-Xincgc參數啓動該GC。

4種GC的具體描述參見[3]。

二.Tomcat配置

問題分析:

   由於TOMCAT內存溢出而引發的問題,主要原因是JVM的虛擬內存默認爲128M,當超過這個值時就把先前佔用的內存釋放,而導致好象TCP/IP丟包的假象,出現HTTP500的錯誤。解決方法主要是加大TOMCAT可利用內存,並在程序當中加大內存使用。

解決方法:

方法:加大TOMCAT可利用內存:

  在TOMCAT的目錄下,也就是在TOMCAT41/bin/catalina.bat文件最前面加入

  set JAVA_OPTS=-Xms800m -Xmx800m

  表現效果是當你啓動TOMCAT時,系統內存會增加近800M使用

操作方法:

  1)、先關掉WINDOWS服務當中的TOMCAT4服務。

  2)、再找到TOMCAT/BIN目錄下startup.bat,雙擊打開它,你會發現現WINDOWS內存佔用會增加近800M。

  3)、執行程序,因爲是TOMCAT重新編譯程序,所以第一次會比較慢。

結論:

經過測試,我們得出如下數據:

當系統傳輸約2000條數據時,大約近12M的淨數據(不壓縮時),系統輔助運行的內存大約佔用150M左右的空間,也就是近200M的內存佔用,而我們擴大了近800M的JAVA內存使用,這對於業務本身來說是足夠了。所以你們不用擔心大數據量的傳遞問題。

基於JAVA虛擬機的原理,JAVA自動有垃圾回收機制,也就是在你對一些內存長時間不使用時(近2分鐘,取決於使用頻度和優先級等),就會自動垃圾回收,從而釋放不用的內存佔用。

三.WebLogic配置:

由於WebLogic的配置問題,我們的測試出現了失敗情況。原因是爲WebLogic分配的內存太少了。通過修改commom\bin\commEnv.cmd文件來增加內存分配。

修改的部分如下:

:bea

if"%PRODUCTION_MODE%" == "true" goto bea_prod_mode

setJAVA_VM=-jrockit

setMEM_ARGS=-Xms768m -Xmx1024m

setJAVA_OPTIONS=%JAVA_OPTIONS% -Xverify:none

gotocontinue

:bea_prod_mode

setJAVA_VM=-jrockit

setMEM_ARGS=-Xms768m -Xmx1024m//原來是128M~256M,太小了,數據太大

gotocontinue

結果修改後,沒有效果。還是有失敗的情況。

發現,原來,在:bea下面還有一段配置信息如下:

:sun

if"%PRODUCTION_MODE%" == "true" goto sun_prod_mode

setJAVA_VM=-client

setMEM_ARGS=-Xms768m -Xmx1024m -XX:MaxPermSize=256m

setJAVA_OPTIONS=%JAVA_OPTIONS% -Xverify:none

gotocontinue

:sun_prod_mode

setJAVA_VM=-server

setMEM_ARGS=-Xms768m -Xmx1024m -XX:MaxPermSize=256m

gotocontinue

將這裏的內存分配修改後見效。

原因是,上面對第一段代碼是爲bea自己的JVM設置的,下面的是爲Sun的設置的。而WebLogic默認的是Sun的,所以出了毛病。在JDK的選擇上,weblogic有兩種JDK供選擇,一種是Sun的JDK,另外一種是Bea的jrockit。按照bea的網站的說明,sunjdk提供更好的兼容性,而使用jrockit可以提供更好的性能。作爲weblogic集羣我全部採用jrockit作爲JDK環境,以達到更高的性能。

在默認啓動情況下,jrockit啓動時爲其窗口配置的內存大小比較小。注意weblogic的啓動內存配置-Xms32m -Xmx256m,通過修改commEnv.sh可以修改這個參數,Xms表示啓動開始分配的內存,Xmx表示最大能分配的內存,這裏我們根據應用情況調整爲-Xms1536m -Xmx1536m,這點需要根據自身測試情況和系統配置進行調整,經過週一晚的調試,我們目前應用比較合理的窗口內存大小爲1536M(2G× 75%),通過top可以觀察到測試中的內存反應,最合理的應該是恰好把物理內存用完。

 


 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章