JVM Tomcat性能實戰

本節只是介紹實戰部分，具體的理論參數，請自行百度。

所需工具：linux服務器  Jmeter測試工具  xshell   一個web應用

 

Tomcat的JVM參數能夠配置在catalina.sh，若是是在window上能夠配置.bat文件

配置1：

這裏 我配置了一個gc日誌路徑爲/home/log/gc.log ,打印gc的日誌，初始堆和最大堆內存設置爲50M，輸出Dump文件在內存溢出的時候 ，使用串行垃圾收集器，永久代大小爲50m。

將web應用放到對應的目錄，配置好server.xml（這裏不做配置介紹），sh start.sh啓動tomcat.

 

使用壓測工具（Jmeter）進行吞吐量的測試。沒用過的同窗能夠上官網下載學習一下http://jmeter.apache.org/

創建用戶組（10個線程，每一個線程請求1000次），設置好Http請求的信息，生成一個聚合報告和一個gc日誌

先來看一下gc日誌吧：

滿屏幕的Full GC啊，並且觀察第一列時間戳變化結合用時能夠發現，幾乎上一次Full GC尚未結束，下一次又來了，真是一波還未平息，一波又來侵襲啊！

最後查看jmeter上給出的聚合報告：

 

吞吐量維持在122.7每秒。從這個案例中咱們能夠看到老年代34176k基本已經滿了，通過FUll GC以後新生代會有一點剩餘的空間。總的來講Full GC的停頓時間是最長的，並且發生的這麼頻繁，顯然這樣的配置是不合理的。

 

 

配置2：

此次配置主要是增大了最大堆內存。以便虛擬機自動擴容，獲得穩定的堆內存大小。

 

只須要關注一點 最大堆內存爲82924k 80M左右，也就是說虛擬機對堆內存自動擴容到80M，而且穩定下來。這個配置測試只是爲了找到一個穩定的堆內存，以便接下來的測試。

 

配置三：

設置堆的初始內存128m。

由配置2的結果可知，堆內存最終穩定在80m左右，所以小於80m的堆內存，頗有可能會引發大量的GC反應，因此這裏我把堆內存設置爲128M，能夠減小GC次數。

能夠看到吞吐量略微有所提高，GC次數大量減小，而且GC的時間間隔變得更長。

配置四:

當前使用ParallalGC回收器，這是一個多線程並行回收器。

使用多線程並行的GC回收器吞吐量有略微有提高。（在沒有GC壓力的狀況下，ParallalGC與serialGC的差別對吞吐量影響並不大。）

 

配置五：

 

配置六：

 

根據配置三的結論在80M如下的堆內存會發生頻繁的GC，再結合配置四中獲得的結論在有必定GC壓力的時候，ParallelGC和serialGC的差別會在吞吐量有必定的體現。配置五和配置六的堆內存爲64M  （小於80M） ，因此會發生頻繁的GC,在採用不一樣的GC回收器的時候，理論上會在在吞吐量上有較大的差別性，可是個人實驗爲何差距不是很大，到底爲何呢？   誒， 家裏窮，我用的是單核的CPU，在單核的狀況下ParallelGC改變性能並不明顯。在單核或者並行能力較弱的狀況下仍是推薦使用serialGC。有條件的同窗能夠用多核的服務器試一下哦！並告知結果，讓本人體會一下糕富帥的生活。

 

配置七：

用ParNewGC試試，新生代使用ParNewGC回收，老年代依舊使用SerialGC回收。看看性能如何？

比所有使用串行回收器的性能好，可是比所有使用並行回收器的性能差些。

 

另外JDK版本的升級可能也會使得性能有一點的提高，這能夠說是免費的午飯，可是JDK版本升級伴隨着必定的風險，也許在新版本的JDK中引入某些未知的BUG，畢竟吃人家的嘴軟，出來混的仍是要還的！

 

---

 

 

最後我列出一些經常使用的JVM配置參數供參考：

1.與串行回收期相關的參數

    •-XX:+UseSerialGC:在新生代和老年代使用串行的收集器

    •-XX:SurvivorRatio:設置eden區的大小和survivor區的比例

    •-XX:PretenureSizeThreshold:設置大對象直接進入老年代的閥值。當對象的大小超過這個值，將直接在老年代分配

    •-XX:MaxTenuringThreshold:設置對象進入老年代的年齡的最大值。每一次Minor GC後，對象年齡就加1.任何大於這個年齡的對象，必定會進入老年代。

2.與並行GC相關的參數

   •-XX:+UseParNewGC:在新生代使用並行收集器。

   •-XX:+UseParallelOldGC:在老年代使用並行收集器

   •-XX:+ParallelGCThreads:設置用於垃圾回收的線程數，一般能夠設置成和CPU數相等。CPU數量較多的狀況下，設置相對小的數值也可。

   •-XX:+MaxGCPauseMillis:設置最大垃圾收集停頓時間。它的值是一個大於0的整數。收集器在工做時，會調整java堆的大小或其餘的一些參數，儘量把停頓時間控制在MaxGCPauseMillis之內。

   •-XX：+UseAdaptiveSizePolicy:打開自適應GC策略，在這種模式下，新生代的大小和survivior的比例，晉升老年代的對象年齡等參數會被自動的調整，以達到堆大小，吞吐量和停頓之間的平衡點。

   •-XX:+GCTimeRatio:設置吞吐量大小。它的值是一個0到100之間的證書。假設GCTimeRatio的值爲n,那麼系統將花費不超過1/(1+n)的時間用於垃圾收集。

3.與CMS收集器相關的參數

   •-XX:+UseConcMarkSweepGC:新生代使用並行收集器，老年代使用CMS+串行收集器。

   •-XX:ParallelCMSThreads:設置CMS的線程數量。

   •-XX:CMSInitiatingOccupancyFraction:設置CMS收集器在老年代空間被使用多少後觸發，默認68%

   •-XX:UseCMSCompactAtFullCollection:設置CMS在完成垃圾收集後是否要進行一次碎片整理

   •-XX:CMSFullGCBeforeCompaction:設定進行多少次CMS垃圾回收後，進行一次內存壓縮。

   •-XX:+CMSClassUnloadingEnabled:容許對類元數據進行回收

   •-XX:CMSInitiatingPermOccupancyFraction:當永久代佔有率達到這一百分比時，啓動CMS回收（前提是-XX:+CMSClassUnloadingEnabled被激活了）

   •-XX:UseCMSInitiatingOccupancyOnly:表示只有在到達閥值的時候才進行CMS回收。

   •-XX:+CMSIncrementalMode:使用增量模式，比較適合單CPU.增量模式在中標記爲廢棄，jdk9中將完全移除

4.與G1回收期相關的參數

   •-XX:+UseG1GC:使用G1回收器

   •-XX:+MaxGCPauseMillis:設置最大的垃圾收集停頓時間

   •-XX:+GcPauseIntervalMillis:設置停頓時間間隔。

5.TLAB相關

   •-XX:+UseTLAB:開啓TLAB分配。

   •-XX:+PrintTLAB:打印TLAB相關分配信息

   •-XX:TLABSize:設置TLAB大小

   •-XX:+ResizeTLAB:自動調整TLAB大小

6.其餘一些參數

   •-XX:+DisableExplicitGC:禁用顯式GC

   •-XX:+ExplicitGCInvokesConcurrent:使用併發方式處理顯式GC