本節(jié)只是介紹實戰(zhàn)部分，具體的理論參數(shù)，請自行百度。

所需工具：linux服務(wù)器  Jmeter測試工具  xshell   一個web應(yīng)用

Tomcat的JVM參數(shù)可以配置在catalina.sh，如果是在window上可以配置.bat文件

配置1：

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

將web應(yīng)用放到對應(yīng)的目錄，配置好server.xml（這里不作配置介紹），sh start.sh啟動tomcat.

使用壓測工具（Jmeter）進行吞吐量的測試。沒用過的同學可以上官網(wǎng)下載學習一下http://jmeter.apache.org/

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

先來看一下gc日志吧：

滿屏幕的Full GC啊，最后查看聚合報告：

吞吐量維持在122.7每秒。從這個案例中我們可以看到老年代34176k基本已經(jīng)滿了，經(jīng)過FUllGC之后新生代會有一點剩余的空間?？偟膩碚fFull GC的停頓時間是最長的，而且發(fā)生的這么頻繁，顯然這樣的配置是不合理的。

配置2：

這次配置主要是增大了最大堆內(nèi)存。以便虛擬機自動擴容，得到穩(wěn)定的堆內(nèi)存大小。

只需要關(guān)注一點 最大堆內(nèi)存為82924k 80M左右，也就是說虛擬機對堆內(nèi)存自動擴容到80M，并且穩(wěn)定下來。這個配置測試只是為了找到一個穩(wěn)定的堆內(nèi)存，以便接下來的測試。

配置三：

設(shè)置堆的初始內(nèi)存128m。

由配置2的結(jié)果可知，堆內(nèi)存最終穩(wěn)定在80m左右，因此小于80m的堆內(nèi)存，很有可能會引起大量的GC反應(yīng)，所以這里我把堆內(nèi)存設(shè)置為128M，可以減少GC次數(shù)。

可以看到吞吐量略微有所提升，GC次數(shù)大量減少，并且GC的時間間隔變得更長。

配置四:

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

使用多線程并行的GC回收器吞吐量有略微有提升。（在沒有GC壓力的情況下，ParallalGC和serialGC對吞吐量影響不大。）

配置五：

配置六：

根據(jù)配置三的結(jié)論在80M以下的堆內(nèi)存會發(fā)生頻繁的GC，再結(jié)合配置四中得到的結(jié)論在有一定GC壓力的時候，ParallelGC和serialGC的吞吐量會表現(xiàn)出一定的差異性。配置五和配置六的堆內(nèi)存64M<80M ，會發(fā)生頻繁的GC,采用不同的GC回收器的時候，理論上會在在吞吐量上有較大的差異性，但是我的實驗為什么差距不是很大，到底為什么呢？   誒， 家里窮，我用的是單核的CPU，在單核的情況下ParallelGC改變性能并不明顯。在單核或者并行能力較弱的情況下還是推薦使用serialGC。有條件的同學可以用多核的服務(wù)器試一下哦！

配置七：

用ParNewGC試試，新生代使用ParNewGC回收，老年代依舊使用SerialGC回收?？纯葱阅苋绾危?/p>

比全部使用串行回收器的性能好，但是比全部使用并行回收器的性能差些。

另外JDK版本的升級可能也會使得性能有一點的提升，但是JDK版本升級伴隨著一定的風險，也許在新版本的JDK中引入某些未知的BUG.

最后我列出一些常用的JVM配置參數(shù)供參考：

1. 與串行回收期相關(guān)的參數(shù)

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

    •-XX:SurvivorRatio:設(shè)置eden區(qū)的大小和survivor區(qū)的比例

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

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

2. 與并行GC相關(guān)的參數(shù)

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

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

   •-XX:+ParallelGCThreads:設(shè)置用于垃圾回收的線程數(shù)，通?？梢栽O(shè)置成和CPU數(shù)相等。CPU數(shù)量較多的情況下，設(shè)置相對小的數(shù)值也可。

   •-XX:+MaxGCPauseMillis:設(shè)置最大垃圾收集停頓時間。它的值是一個大于0的整數(shù)。收集器在工作時，會調(diào)整java堆的大小或其他的一些參數(shù)，盡可能把停頓時間控制在MaxGCPauseMillis以內(nèi)。

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

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

3. 與CMS收集器相關(guān)的參數(shù)

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

   •-XX:ParallelCMSThreads:設(shè)置CMS的線程數(shù)量。

   •-XX:CMSInitiatingOccupancyFraction:設(shè)置CMS收集器在老年代空間被使用多少后觸發(fā)，默認68%

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

   •-XX:CMSFullGCBeforeCompaction:設(shè)定進行多少次CMS垃圾回收后，進行一次內(nèi)存壓縮。

   •-XX:+CMSClassUnloadingEnabled:允許對類元數(shù)據(jù)進行回收

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

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

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

4. 與G1回收期相關(guān)的參數(shù)

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

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

   •-XX:+GcPauseIntervalMillis:設(shè)置停頓時間間隔。

5. TLAB相關(guān)

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

   •-XX:+PrintTLAB:打印TLAB相關(guān)分配信息

   •-XX:TLABSize:設(shè)置TLAB大小

   •-XX:+ResizeTLAB:自動調(diào)整TLAB大小

6. 其他一些參數(shù)

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

   •-XX:+ExplicitGCInvokesConcurrent:使用并發(fā)方式處理顯式GC

以上這篇JVM Tomcat性能實戰(zhàn)(推薦)就是小編分享給大家的全部內(nèi)容了，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論