腳本之家服務(wù)器常用軟件

快捷導(dǎo)航

JVM Tomcat性能實(shí)戰(zhàn)(推薦)

更新時(shí)間：2016年05月19日 16:43:12 投稿：jingxian

下面小編就為大家?guī)?lái)一篇JVM Tomcat性能實(shí)戰(zhàn)(推薦)。小編覺(jué)得挺不錯(cuò)的，現(xiàn)在就分享給大家，也給大家做個(gè)參考。一起跟隨小編過(guò)來(lái)看看吧

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

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

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

配置1：

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

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

使用壓測(cè)工具（Jmeter）進(jìn)行吞吐量的測(cè)試。沒(méi)用過(guò)的同學(xué)可以上官網(wǎng)下載學(xué)習(xí)一下http://jmeter.apache.org/

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

先來(lái)看一下gc日志吧：

滿屏幕的Full GC啊，最后查看聚合報(bào)告：

吞吐量維持在122.7每秒。從這個(gè)案例中我們可以看到老年代34176k基本已經(jīng)滿了，經(jīng)過(guò)FUllGC之后新生代會(huì)有一點(diǎn)剩余的空間。總的來(lái)說(shuō)Full GC的停頓時(shí)間是最長(zhǎng)的，而且發(fā)生的這么頻繁，顯然這樣的配置是不合理的。

配置2：

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

只需要關(guān)注一點(diǎn) 最大堆內(nèi)存為82924k 80M左右，也就是說(shuō)虛擬機(jī)對(duì)堆內(nèi)存自動(dòng)擴(kuò)容到80M，并且穩(wěn)定下來(lái)。這個(gè)配置測(cè)試只是為了找到一個(gè)穩(wěn)定的堆內(nèi)存，以便接下來(lái)的測(cè)試。

配置三：

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

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

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

配置四:

當(dāng)前使用ParallalGC回收器，這是一個(gè)多線程并行回收器。

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

配置五：

配置六：

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

配置七：

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

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

另外JDK版本的升級(jí)可能也會(huì)使得性能有一點(diǎn)的提升，但是JDK版本升級(jí)伴隨著一定的風(fēng)險(xiǎn)，也許在新版本的JDK中引入某些未知的BUG.

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

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

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

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

•-XX:PretenureSizeThreshold:設(shè)置大對(duì)象直接進(jìn)入老年代的閥值。當(dāng)對(duì)象的大小超過(guò)這個(gè)值，將直接在老年代分配

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

•-XX:UseCMSInitiatingOccupancyOnly:表示只有在到達(dá)閥值的時(shí)候才進(jìn)行CMS回收。

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

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