jvm參數調優

原博客地址： http://niyunjiu.iteye.com/blog/337266

PE2950 8G  雙cpu，每cpu四核，raid1，兩個tomcat6.0.14

 

JAVA_OPTS='-server -Xms2560m -Xmx2560m -Xmn768m -XX:PermSize=128m -XX:MaxPermSize=256m <strong>-Xss256k  </strong>
 -XX:ParallelGCThreads=6 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:MaxTenuringThreshold=5 -XX:SurvivorRatio=8 -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError -Xloggc:/var/log/boss/gc-a.log -Djava.awt.headless=true -XX:+DisableExplicitGC -Dlog.home=/var/log/boss/boss-a -Dorg.apache.jasper.compiler.Parser.STRICT_QUOTE_ESCAPING=false'

 

 曾用過的：

#JAVA_OPTS='-server -Xms2560m -Xmx2560m -Xmn768m -XX:PermSize=128m -XX:MaxPermSize=256m -XX:ParallelGCThreads=6 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:MaxTenuringThreshold=5 -XX:SurvivorRatio=8 -verbose:gc -XX:+PrintGCDetails -Xloggc:/var/log/boss/gc-a.log -Djava.awt.headless=true -XX:+ExplicitGCInvokesConcurrent -Dlog.home=/var/log/boss/boss-a -Dorg.apache.jasper.compiler.Parser.STRICT_QUOTE_ESCAPING=false'
#JAVA_OPTS='-server -Xms2048m -Xmx2048m -Xmn768m -XX:PermSize=128m -XX:MaxPermSize=256m -XX:ParallelGCThreads=4 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -Djava.awt.headless=true -XX:+DisableExplicitGC -Xloggc:/var/log/boss/gc-a.log -Dlog.home=/var/log/boss/boss-a'
#JAVA_OPTS='-server -Xms2048m -Xmx2048m -Xmn512m -XX:PermSize=128m -XX:MaxPermSize=256m -XX:ParallelGCThreads=4 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -Djava.awt.headless=true -XX:+DisableExplicitGC -XX:+HeapDumpOnOutOfMemoryError -XX:+PrintGCDetails -XX:+PrintHeapAtGC -Xloggc:/var/log/boss/gc-a.log -Dlog.home=/var/log/boss/boss-a -XX:+PrintGCTimeStamps -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCApplicationConcurrentTime -XX:+ExplicitGCInvokesConcurrent'

 

 

  其它重要選項

-verbose:gc

-XX:+UseParallelOldGC（請注意，並行縮並在與併發標記清除（mark-sweep）收集器結合使用時不可用；它只能和並行年輕代收集器（-XX:+UseParallelGC）一起使用）

-XX:+ExplicitGCInvokesConcurrent

提示：一般的Young Generation的大小是整個Heap size的1/4。Young generation的minor收集率應一般在70％以上。當然在實際的應用中需要根據具體情況進行調整。

 

http://blog.csdn.net/feng_sundy/archive/2007/01/02/1472316.aspx

http://www.tot.name/show/3/7/20061112220201.htm

http://calvin.iteye.com/blog/212967

-Xrunhprof:heap=sites

 

GC日誌分析工具：

GC portal

http://java.sun.com/developer/technicalArticles/Programming/GCPortal/

HPjmeter

Jtune

gcviewer

 

JVM 選項全集：

http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp

 

 

 

調優總結：

http://unixboy.iteye.com/blog/174173

 

http://calvin.iteye.com/blog/91905

 

http://wxw850227.iteye.com/blog/255242

 

http://sdh5724.iteye.com/blog/283977

 

<本文提供的設置僅僅是在高壓力， 多CPU， 高內存環境下設置> 

最近對JVM的參數重新看了下， 把應用的JVM參數調整了下。  幾個重要的參數

-server -Xmx3g -Xms3g -XX:MaxPermSize=128m 
-XX:NewRatio=1  eden/old 的比例
-XX:SurvivorRatio=8  s/e的比例 
-XX:+UseParallelGC 
-XX:ParallelGCThreads=8  
-XX:+UseParallelOldGC  這個是JAVA 6出現的參數選項 
-XX:LargePageSizeInBytes=128m 內存頁的大小， 不可設置過大， 會影響Perm的大小。 
-XX:+UseFastAccessorMethods 原始類型的快速優化 
-XX:+DisableExplicitGC  關閉System.gc()



另外 -Xss 是線程棧的大小， 這個參數需要嚴格的測試， 一般小的應用， 如果棧不是很深， 應該是128k夠用的， 不過，我們的應用調用深度比較大， 還需要做詳細的測試。 這個選項對性能的影響比較大。 建議使用256K的大小.

例子:

-server -Xmx3g -Xms3g -Xmn=1g -XX:MaxPermSize=128m -Xss256k  -XX:MaxTenuringThreshold=10 -XX:+DisableExplicitGC -XX:+UseParallelGC -XX:+UseParallelOld GC -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods -XX:+AggressiveOpts -XX:+UseBiasedLocking　

 

-XX:+PrintGCApplicationStoppedTime -XX:+PrintGCTimeStamps -XX:+PrintGCDetails 打印參數

=================================================================

另外對於大內存設置的要求:

Linux : 
Large page support is included in 2.6 kernel. Some vendors have backported the code to their 2.4 based releases. To check if your system can support large page memory, try the following:   

# cat /proc/meminfo | grep Huge
HugePages_Total: 0
HugePages_Free: 0
Hugepagesize: 2048 kB
#



If the output shows the three "Huge" variables then your system can support large page memory, but it needs to be configured. If the command doesn't print out anything, then large page support is not available. To configure the system to use large page memory, one must log in as root, then:

1. Increase SHMMAX value. It must be larger than the Java heap size. On a system with 4 GB of physical RAM (or less) the following will make all the memory sharable:
   
   # echo 4294967295 > /proc/sys/kernel/shmmax
   
   
2. Specify the number of large pages. In the following example 3 GB of a 4 GB system are reserved for large pages (assuming a large page size of 2048k, then 3g = 3 x 1024m = 3072m = 3072 * 1024k = 3145728k, and 3145728k / 2048k = 1536): 
   
   # echo 1536 > /proc/sys/vm/nr_hugepages
   
   

Note the /proc values will reset after reboot so you may want to set them in an init script (e.g. rc.local or sysctl.conf).

=============================================
這個設置， 目前觀察下來的結果是EDEN區域收集明顯速度比較快， 最多幾個ms, 但是，對於FGC， 大約需要0。9， 但是發生時間非常的長， 應該是影響不大。 但是對於非web應用的中間件服務, 這個設置很要不得, 可能導致很嚴重延遲效果. 因此, CMS必然需要被使用, 下面是CMS的重要參數介紹

關於CMS的設置:

使用CMS的前提條件是你有比較的長生命對象， 比如有200M以上的OLD堆佔用。 那麼這個威力非常猛， 可以極大的提高的FGC的收集能力。 如果你的OLD佔用非常的少， 別用了， 絕對降低你性能， 因爲CMS收集有2個STOP WORLD的行爲。 OLD少的清情況， 根據我的測試， 使用並行收集參數會比較好。

-XX:+UseConcMarkSweepGC   使用CMS內存收集
-XX:+AggressiveHeap 特別說明下：(我感覺對於做java cache應用有幫助)

• 試圖是使用大量的物理內存
• 長時間大內存使用的優化，能檢查計算資源（內存， 處理器數量）
• 至少需要256MB內存
• 大量的CPU／內存， （在1.4.1在4CPU的機器上已經顯示有提升）

-XX:+UseParNewGC 允許多線程收集新生代
-XX:+CMSParallelRemarkEnabled  降低標記停頓

-XX+UseCMSCompactAtFullCollection  在FULL GC的時候， 壓縮內存， CMS是不會移動內存的， 因此， 這個非常容易產生碎片， 導致內存不夠用， 因此， 內存的壓縮這個時候就會被啓用。 增加這個參數是個好習慣。 

 

壓力測試下合適結果：

-server -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xmx2g -Xms2g -Xmn256m -XX:PermSize=128m -Xss256k -XX:MaxTenuringThreshold=31 -XX:+DisableExplicitGC  -XX:+UseConcMarkSweepGC -XX:+UseParNewGC  -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:LargePageSizeInBytes=128m  -XX:+UseFastAccessorMethods

 

由於Jdk1.5.09及之前的bug, 因此， CMS下的GC， 在這些版本的表現是十分糟糕的。  需要另外2個參數來控制cms的啓動時間：

-XX:+UseCMSInitiatingOccupancyOnly   僅僅使用手動定義初始化定義開始CMS收集

-XX:CMSInitiatingOccupancyFraction=70  CMS堆上， 使用70％後開始CMS收集。

 

使用CMS的好處是用盡量少的新生代、，我的經驗值是128M－256M， 然後老生代利用CMS並行收集， 這樣能保證系統低延遲的吞吐效率。 實際上cms的收集停頓時間非常的短，2G的內存， 大約20－80ms的應用程序停頓時間。

 

=========系統情況介紹＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

這個例子是測試系統12小時運行後的情況：

$uname -a

2.4.21-51.EL3.customsmp #1 SMP Fri Jun 27 10:44:12 CST 2008 i686 i686 i386 GNU/Linux

 

$ free -m
             total       used       free     shared    buffers     cached
Mem:          3995       3910         85          0        162       1267
-/+ buffers/cache:       2479       1515
Swap:         2047          0       2047

 

$ jstat -gcutil 23959 1000

 S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT   
 59.06   0.00  45.77  44.45  56.88  15204  324.023    66    1.668  325.691
  0.00  39.66  27.53  44.73  56.88  15205  324.046    66    1.668  325.715
 53.42   0.00  22.80  44.73  56.88  15206  324.073    66    1.668  325.741
  0.00  44.90  13.73  44.76  56.88  15207  324.094    66    1.668  325.762
 51.70   0.00  19.03  44.76  56.88  15208  324.118    66    1.668  325.786
  0.00  61.62  19.44  44.98  56.88  15209  324.148    66    1.668  325.816
 53.03   0.00  14.00  45.09  56.88  15210  324.172    66    1.668  325.840
 53.03   0.00  87.87  45.09  56.88  15210  324.172    66    1.668  325.840
  0.00  50.49  72.00  45.22  56.88  15211  324.198    66    1.668  325.866

 

GC參數配置：

JAVA_OPTS=" -server -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xmx2g -Xms2g -Xmn256m -XX:PermSize=128m -Xss256k -XX:MaxTenuringThreshold=31 -XX:+DisableExplicitGC  -XX:+UseConcMarkSweepGC -XX:+UseParNewGC  -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:LargePageSizeInBytes=128m  -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70 "

實際上我們可以看到並行young gc執行時間是： 324.198s／15211＝20ms, cms的執行時間是 1.668／66＝25ms. 當然嚴格來說， 這麼算是不對的， 世界停頓的時間要比這是數據稍微大5-10ms. 對我們來說如果不輸出日誌， 對我們是有參考意義的。

 

32位系統下， 設置成2G， 非常危險， 除非你確定你的應用佔用的native內存很少， 不然可能導致jvm直接crash。

 

-XX:+AggressiveOpts 加快編譯

-XX:+UseBiasedLocking 鎖機制的性能改善。