详解JVM参数调优技巧总结

Mar 31, 2017 pm 03:04 PM

你对JVM参数调优的概念了解多少,这里和大家分享一下其方法,如果设置的不好,JVM不断执行FullGC,将导致整个系统变得很慢,网站停滞时间能达10秒以上,这种情况如果没隔几分钟就来一次,自己都受不了。 JVM参数调优实例解析 关于JVM参数调优,对于很多程序

 

你对JVM参数调优的概念了解多少,这里和大家分享一下其方法,如果设置的不好,JVM不断执行FullGC,将导致整个系统变得很慢,网站停滞时间能达10秒以上,这种情况如果没隔几分钟就来一次,自己都受不了。

JVM参数调优实例解析

关于JVM参数调优,对于很多程序员来说都是很头痛的问题,如果设置的不好,JVM不断执行FullGC,将导致整个系统变得很慢,网站停滞时间能达10秒以上,这种情况如果没隔几分钟就来一次,自己都受不了。

这种停滞在测试的时候看不出来,只有网站pv达到数十万/天的时候问题就暴露出来了,要想配置好JVM参数,需要对年轻代、年老代、救助空间和永久代有一定了解,还要了解JVM内存管理逻辑,最终还要根据自己的应用来做调整。关于JVM参数上网一搜就能搜出一大把,也有很多提供实践的例子,我也按照各种例子测试过,最终还是会出现问题,经过几个月的实践改善,我就网站(要求无停滞时间)的jvm参数调优给出以下几条经验。

1:建议用64位操作系统,Linux下64位的JDK比32位JDK要慢一些,但是吃得内存更多,吞吐量更大。

2:XMX和XMS设置一样大,MaxPermSize和MinPermSize设置一样大,这样可以减轻伸缩堆大小带来的压力。

3:调试的时候设置一些打印参数,如-XX:+PrintClassHistogram-XX:+PrintGCDetails-XX:+PrintGCTimeStamps-XX:+PrintHeapAtGC-Xloggc:log/gc.log,这样可以从gc.log里看出一些端倪出来。

4:系统停顿的时候可能是GC的问题也可能是程序的问题,多用Jmap和Jstack查看,或者killall-3Java,然后查看Java控制台日志,能看出很多问题。有一次,网站突然很慢,Jstack一看,原来是自己写的URLConnection连接太多没有释放,改一下程序就OK了。

5:仔细了解自己的应用,如果用了缓存,那么年老代应该大一些,缓存的HashMap不应该无限制长,建议采用LRU算法的Map做缓存,LRUMap的最大长度也要根据实际情况设定。

6:垃圾回收时PromotionFailed是个很头痛的问题,一般可能是两种原因产生,第一个原因是救助空间不够,救助空间里的对象还不应该被移动到年老代,但年轻代又有很多对象需要放入救助空间;第二个原因是年老代没有足够的空间接纳来自年轻代的对象;这两种情况都会转向FullGC,网站停顿时间较长。第一个原因我的最终解决办法是去掉救助空间,设置-XX:SurvivorRatio=65536-XX:MaxTenuringThreshold=0即可,第二个原因我的解决办法是设置CMSInitiatingOccupancyFraction为某个值(假设70),这样年老代空间到70%时就开始执行CMS,年老代有足够的空间接纳来自年轻代的对象。

7:不管怎样,永久代还是会逐渐变满,所以隔三差五重起Java服务器是必要的,我每天都自动重起。

8:采用并发回收时,年轻代小一点,年老代要大,因为年老大用的是并发回收,即使时间长点也不会影响其他程序继续运行,网站不会停顿,我的最终配置如下(系统8G内存),每天几百万PV一点问题都没有,网站没有停顿,2009年网站没有因为内存问题down过机。

$JAVA_ARGS.="-Dresin.home=$SERVER_ROOT-server  
-Xms6000M-Xmx6000M-Xmn500M-XX:PermSize=500M   
-XX:MaxPermSize=500M-XX:SurvivorRatio=65536-XX:MaxTenuringThreshold=0-Xnoclassgc  
-XX:+DisableExplicitGC-XX:+UseParNewGC-XX:+UseConcMarkSweepGC   
-XX:+UseCMSCompactAtFullCollection-XX:CMSFullGCsBeforeCompaction=0
-XX:+CMSClassUnloadingEnabled-XX:-CMSParallelRemarkEnabled   
-XX:CMSInitiatingOccupancyFraction=90-XX:SoftRefLRUPolicyMSPerMB=0-XX:+PrintClassHistogram   
-XX:+PrintGCDetails-XX:+PrintGCTimeStamps-XX:+PrintHeapAtGC-Xloggc:log/gc.log";
ログイン後にコピー

说明一下,-XX:SurvivorRatio=65536-XX:MaxTenuringThreshold=0就是去掉了救助空间:

◆-Xnoclassgc禁用类垃圾回收,性能会高一点;
◆-XX:+DisableExplicitGC禁止System.gc(),免得程序员误调用gc方法影响性能;
◆-XX:+UseParNewGC,对年轻代采用多线程并行回收,这样收得快;带CMS参数的都是和并发回收相关的。

CMSInitiatingOccupancyFraction

这个JVM参数设置有很大技巧,基本上满足(Xmx-Xmn)*(100-CMSInitiatingOccupancyFraction)/100>=Xmn就不会出现promotionfailed。在我的应用中Xmx是6000,Xmn是500,那么Xmx-Xmn是5500兆,也就是年老代有5500兆,CMSInitiatingOccupancyFraction=90说明年老代到90%满的时候开始执行对年老代的并发垃圾回收(CMS),这时还剩10%的空间是5500*10%=550兆,所以即使Xmn(也就是年轻代共500兆)里所有对象都搬到年老代里,550兆的空间也足够了,所以只要满足上面的公式,就不会出现垃圾回收时的PromotionFailed;

SoftRefLRUPolicyMSPerMB

这个参数我认为可能有点用,官方解释是softlyreachableobjectswillremainaliveforsomeamountoftimeafterthelasttimetheywerereferenced.

Thedefaultvalueisonesecondoflifetimeperfreemegabyteintheheap,我觉得没必要等1秒;

网上其他介绍JVM参数的也比较多,估计其中大部分是没有遇到PromotionFailed,或者访问量太小没有机会遇到,(Xmx-Xmn)*(100-CMSInitiatingOccupancyFraction)/100>=Xmn这个公式绝对是原创,真遇到PromotionFailed了,还得这么处理。

这里和大家分享一下JVM参数调优的八条经验,JVM参数调优,这是很头痛的问题,设置的不好,JVM不断执行FullGC,导致整个系统变得很慢,网站停滞时间能达10秒以上,相信通过本文的学习你对JVM参数调优有新的认识。

实例讲解JVM参数调优的八条经验

本文将介绍JVM参数调优,这是很头痛的问题,设置的不好,JVM不断执行FullGC,导致整个系统变得很慢,网站停滞时间能达10秒以上,这种情况如果没隔几分钟就来一次,自己都受不了。这种停滞在测试的时候看不出来,只有网站pv达到数十万/天的时候问题就暴露出来了。

要想配置好JVM参数,需要对年轻代、年老代、救助空间和永久代有一定了解,还要了解jvm内存管理逻辑,最终还要根据自己的应用来做调整。关于JVM参数上网一搜就能搜出一大把,也有很多提供实践的例子,我也按照各种例子测试过,最终还是会出现问题。

经过几个月的实践改善,我就网站(要求无停滞时间)的jvm参数调优给出以下几条经验。

1:建议用64位操作系统,Linux下64位的jdk比32位jdk要慢一些,但是吃得内存更多,吞吐量更大。

2:XMX和XMS设置一样大,MaxPermSize和MinPermSize设置一样大,这样可以减轻伸缩堆大小带来的压力。

3:调试的时候设置一些打印JVM参数,如-XX:+PrintClassHistogram-XX:+PrintGCDetails-XX:+PrintGCTimeStamps-XX:+PrintHeapAtGC-Xloggc:log/gc.log,这样可以从gc.log里看出一些端倪出来。

4:系统停顿的时候可能是GC的问题也可能是程序的问题,多用jmap和jstack查看,或者killall-3java,然后查看java控制台日志,能看出很多问题。有一次,网站突然很慢,jstack一看,原来是自己写的URLConnection连接太多没有释放,改一下程序就OK了。

5:仔细了解自己的应用,如果用了缓存,那么年老代应该大一些,缓存的HashMap不应该无限制长,建议采用LRU算法的Map做缓存,LRUMap的最大长度也要根据实际情况设定。

6:垃圾回收时promotionfailed是个很头痛的问题,一般可能是两种原因产生,第一个原因是救助空间不够,救助空间里的对象还不应该被移动到年老代,但年轻代又有很多对象需要放入救助空间;第二个原因是年老代没有足够的空间接纳来自年轻代的对象;这两种情况都会转向FullGC,网站停顿时间较长。第一个原因我的最终解决办法是去掉救助空间,设置-XX:SurvivorRatio=65536-XX:MaxTenuringThreshold=0即可,第二个原因我的解决办法是设置CMSInitiatingOccupancyFraction为某个值(假设70),这样年老代空间到70%时就开始执行CMS,年老代有足够的空间接纳来自年轻代的对象。

7:不管怎样,永久代还是会逐渐变满,所以隔三差五重起java服务器是必要的,我每天都自动重起。

8:采用并发回收时,年轻代小一点,年老代要大,因为年老大用的是并发回收,即使时间长点也不会影响其他程序继续运行,网站不会停顿。

我的最终配置如下(系统8G内存),每天几百万pv一点问题都没有,网站没有停顿,2009年网站没有因为内存问题down过机。

$JAVA_ARGS.="-Dresin.home=$SERVER_ROOT  
-server-Xms6000M-Xmx6000M-Xmn500M  
-XX:PermSize=500M-XX:MaxPermSize=500M 
-XX:SurvivorRatio=65536 
-XX:MaxTenuringThreshold=0 
-Xnoclassgc  
-XX:+DisableExplicitGC  XX:+UseParNewGC-XX:+UseConcMarkSweepGC  
-XX:+UseCMSCompactAtFullCollection  
-XX:CMSFullGCsBeforeCompaction=0 
-XX:+CMSClassUnloadingEnabled  
-XX:-CMSParallelRemarkEnabled  
-XX:CMSInitiatingOccupancyFraction=90 
-XX:SoftRefLRUPolicyMSPerMB=0-XX:+PrintClassHistogram  
-XX:+PrintGCDetails-XX:+PrintGCTimeStamps-XX:+PrintHeapAtGC  
-Xloggc:log/gc.log";
ログイン後にコピー

说明一下,-XX:SurvivorRatio=65536,-XX:MaxTenuringThreshold=0就是去掉了救助空间;

-Xnoclassgc禁用类垃圾回收,性能会高一点;

-XX:+DisableExplicitGC禁止System.gc(),免得程序员误调用gc方法影响性能;

-XX:+UseParNewGC,对年轻代采用多线程并行回收,这样收得快;

带CMS参数的都是和并发回收相关的,不明白的可以上网搜索

CMSInitiatingOccupancyFraction,这个参数设置有很大技巧,基本上满足(Xmx-Xmn)*(100-CMSInitiatingOccupancyFraction)/100>=Xmn就不会出现promotionfailed。在我的应用中Xmx是6000,Xmn是500,那么Xmx-Xmn是5500兆,也就是年老代有5500兆,CMSInitiatingOccupancyFraction=90说明年老代到90%满的时候开始执行对年老代的并发垃圾回收(CMS),这时还剩10%的空间是5500*10%=550兆,所以即使Xmn(也就是年轻代共500兆)里所有对象都搬到年老代里,550兆的空间也足够了,所以只要满足上面的公式,就不会出现垃圾回收时的promotionfailed;

SoftRefLRUPolicyMSPerMB这个参数我认为可能有点用,官方解释是softlyreachableobjectswillremainaliveforsomeamountoftimeafterthelasttimetheywerereferenced.

Thedefaultvalueisonesecondoflifetimeperfreemegabyteintheheap,我觉得没必要等1秒;

网上其他介绍JVM参数的也比较多,估计其中大部分是没有遇到promotionfailed,或者访问量太小没有机会遇到,(Xmx-Xmn)*(100-CMSInitiatingOccupancyFraction)/100>=Xmn这个公式绝对是原创,真遇到promotionfailed了,还得这么处理。

/usr/local/jdk/bin/java -Dresin.home=/usr/local/resin -server -Xms1800M -Xmx1800M -Xmn300M -Xss512K 
-XX:PermSize=300M -XX:MaxPermSize=300M -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=5 
-XX:GCTimeRatio=19 -Xnoclassgc -XX:+DisableExplicitGC -XX:+UseParNewGC
 -XX:+UseConcMarkSweepGC -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 
-XX:-CMSParallelRemarkEnabled -XX:CMSInitiatingOccupancyFraction=70 -XX:SoftRefLRUPolicyMSPerMB=0
 -XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps
 -XX:+PrintHeapAtGC -Xloggc:log/gc.log
ログイン後にコピー

堆大小设置

JVM 中最大堆大小有三方面限制:相关操作系统的数据模型(32-bt还是64-bit)限制;系统的可用虚拟内存限制;系统的可用物理内存限制。32位系统下,一般限制在1.5G~2G;64为操作系统对内存无限制。我在Windows Server 2003 系统,3.5G物理内存,JDK5.0下测试,最大可设置为1478m。

典型JVM参数设置:

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k

-Xmx3550m:设置JVM最大可用内存为3550M。

-Xms3550m:设置JVM促使内存为3550m。此值可以设置与-Xmx相同,以避免每次垃圾回收完成后JVM重新分配内存。

-Xmn2g:设置年轻代大小为2G。整个堆大小=年轻代大小 + 年老代大小 + 持久代大小。持久代一般固定大小为64m,所以增大年轻代后,将会减小年老代大小。此值对系统性能影响较大,Sun官方推荐配置为整个堆的3/8。

-Xss128k:设置每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M,以前每个线程堆栈大小为256K。更具应用的线程所需内存大小进行调整。在相同物理内存下,减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的,不能无限生成,经验值在3000~5000左右。

java -Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:MaxPermSize=16m 
-XX:MaxTenuringThreshold=0
ログイン後にコピー

-XX:NewRatio=4:设置年轻代(包括Eden和两个Survivor区)与年老代的比值(除去持久代)。设置为4,则年轻代与年老代所占比值为1:4,年轻代占整个堆栈的1/5

-XX:SurvivorRatio=4:设置年轻代中Eden区与Survivor区的大小比值。设置为4,则两个Survivor区与一个Eden区的比值为2:4,一个Survivor区占整个年轻代的1/6

-XX:MaxPermSize=16m:设置持久代大小为16m。

-XX:MaxTenuringThreshold=0:设置垃圾最大年龄。如果设置为0的话,则年轻代对象不经过Survivor区,直接进入年老代。对于年老代比较多的应用,可以提高效率。如果将此值设置为一个较大值,则年轻代对象会在Survivor区进行多次复制,这样可以增加对象再年轻代的存活时间,增加在年轻代即被回收的概论。

回收器选择

JVM给了三种选择:串行收集器、并行收集器、并发收集器,但是串行收集器只适用于小数据量的情况,所以这里的选择主要针对并行收集器和并发收集器。默认情况下,JDK5.0以前都是使用串行收集器,如果想使用其他收集器需要在启动时加入相应参数。JDK5.0以后,JVM会根据当前系统配置进行判断。

吞吐量优先的并行收集器

如上文所述,并行收集器主要以到达一定的吞吐量为目标,适用于科学技术和后台处理等。

典型JVM参数配置:

java -Xmx3800m -Xms3800m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20
ログイン後にコピー

-XX:+UseParallelGC:选择垃圾收集器为并行收集器。此配置仅对年轻代有效。即上述配置下,年轻代使用并发收集,而年老代仍旧使用串行收集。

-XX:ParallelGCThreads=20:配置并行收集器的线程数,即:同时多少个线程一起进行垃圾回收。此值最好配置与处理器数目相等。

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20 -XX:+UseParallelOldGC

-XX:+UseParallelOldGC:配置年老代垃圾收集方式为并行收集。JDK6.0支持对年老代并行收集。

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100

-XX:MaxGCPauseMillis=100:设置每次年轻代垃圾回收的最长时间,如果无法满足此时间,JVM会自动调整年轻代大小,以满足此值。

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC 
-XX:MaxGCPauseMillis=100 -XX:+UseAdaptiveSizePolicy
ログイン後にコピー

-XX:+UseAdaptiveSizePolicy:设置此选项后,并行收集器会自动选择年轻代区大小和相应的Survivor区比例,以达到目标系统规定的最低相应时间或者收集频率等,此值建议使用并行收集器时,一直打开。

响应时间优先的并发收集器

如上文所述,并发收集器主要是保证系统的响应时间,减少垃圾收集时的停顿时间。适用于应用服务器、电信领域等。

典型JVM参数配置:

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC
ログイン後にコピー

-XX:+UseConcMarkSweepGC:设置年老代为并发收集。测试中配置这个以后,-XX:NewRatio=4的配置失效了,原因不明。所以,此时年轻代大小最好用-Xmn设置。

-XX:+UseParNewGC:设置年轻代为并行收集。可与CMS收集同时使用。JDK5.0以上,JVM会根据系统配置自行设置,所以无需再设置此值。

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseConcMarkSweepGC
 -XX:CMSFullGCsBeforeCompaction=5 -XX:+UseCMSCompactAtFullCollection
ログイン後にコピー

-XX:CMSFullGCsBeforeCompaction:由于并发收集器不对内存空间进行压缩、整理,所以运行一段时间以后会产生“碎片”,使得运行效率降低。此值设置运行多少次GC以后对内存空间进行压缩、整理。

-XX:+UseCMSCompactAtFullCollection:打开对年老代的压缩。可能会影响性能,但是可以消除碎片

辅助信息

JVM提供了大量命令行参数,打印信息,供调试使用。主要有以下一些:

-XX:+PrintGC
ログイン後にコピー

输出形式:

[GC 118250K->113543K(130112K), 0.0094143 secs]   
[Full GC 121376K->10414K(130112K), 0.0650971 secs]  
-XX:+PrintGCDetails
ログイン後にコピー

输出形式:

[GC [DefNew: 8614K->781K(9088K), 0.0123035 secs] 
118250K->113543K(130112K), 0.0124633 secs]   
[GC [DefNew: 8614K->8614K(9088K), 0.0000665 secs]
[Tenured: 112761K->10414K(121024K), 0.0433488 secs] 
121376K->10414K(130112K), 0.0436268 secs]
ログイン後にコピー

-XX:+PrintGCTimeStamps -XX:+PrintGC:PrintGCTimeStamps可与上面两个混合使用

输出形式:11.851: [GC 98328K->93620K(130112K), 0.0082960 secs]

-XX:+PrintGCApplicationConcurrentTime:打印每次垃圾回收前,程序未中断的执行时间。可与上面混合使用

输出形式:Application time: 0.5291524 seconds

-XX:+PrintGCApplicationStoppedTime:打印垃圾回收期间程序暂停的时间。可与上面混合使用

输出形式:Total time for which application threads were stopped: 0.0468229 seconds

-XX:PrintHeapAtGC:打印GC前后的详细堆栈信息

输出形式:

34.702: 
[GC {Heap before gc invocations=7:  def new generation   
total 55296K, used 52568K [0x1ebd0000, 0x227d0000, 0x227d0000)  
eden space 49152K, 99% used 
[0x1ebd0000, 0x21bce430, 0x21bd0000)  
from space 6144K, 55% used 
[0x221d0000, 0x22527e10, 0x227d0000)  to   space 6144K,   
0% used [0x21bd0000, 0x21bd0000, 0x221d0000)  tenured generation   
total 69632K, used 2696K [0x227d0000, 0x26bd0000, 0x26bd0000)  t
he space 69632K,   3% used [0x227d0000, 0x22a720f8, 0x22a72200, 0x26bd0000)  
compacting perm gen total 8192K, used 2898K [0x26bd0000, 0x273d0000, 0x2abd0000)  
the space 8192K, 35% used [0x26bd0000, 0x26ea4ba8, 0x26ea4c00, 0x273d0000)  
ro space 8192K, 66% used [0x2abd0000, 0x2b12bcc0, 0x2b12be00, 0x2b3d0000)  
rw space 12288K, 46% used [0x2b3d0000, 0x2b972060, 0x2b972200, 0x2bfd0000)  
34.735: [DefNew: 52568K->3433K(55296K), 0.0072126 secs] 55264K->6615K(124928K)Heap 
after gc invocations=8:  def new generation   
total 55296K, used 3433K [0x1ebd0000, 0x227d0000, 0x227d0000)  
eden space 49152K,   0% used [0x1ebd0000, 0x1ebd0000, 0x21bd0000)  
from space 6144K, 55% used [0x21bd0000, 0x21f2a5e8, 0x221d0000)  to   
space 6144K,   0% used [0x221d0000, 0x221d0000, 0x227d0000)  
tenured generation   total 69632K, used 3182K [0x227d0000, 0x26bd0000, 0x26bd0000)  
the space 69632K,   4% used [0x227d0000, 0x22aeb958, 0x22aeba00, 0x26bd0000)  
compacting perm gen total 8192K, used 2898K [0x26bd0000, 0x273d0000, 0x2abd0000)  
the space 8192K, 35% used [0x26bd0000, 0x26ea4ba8, 0x26ea4c00, 0x273d0000)  
ro space 8192K, 66% used [0x2abd0000, 0x2b12bcc0, 0x2b12be00, 0x2b3d0000)  
rw space 12288K, 46% used [0x2b3d0000, 0x2b972060, 0x2b972200, 0x2bfd0000)  
}  , 0.0757599 secs]
ログイン後にコピー

-Xloggc:filename:与上面几个配合使用,把相关日志信息记录到文件以便分析。

常见JVM参数配置汇总

堆设置

-Xms:初始堆大小

-Xmx:最大堆大小

-XX:NewSize=n:设置年轻代大小

-XX:NewRatio=n:设置年轻代和年老代的比值。如:为3,表示年轻代与年老代比值为1:3,年轻代占整个年轻代年老代和的1/4

-XX:SurvivorRatio=n:年轻代中Eden区与两个Survivor区的比值。注意Survivor区有两个。如:3,表示Eden:Survivor=3:2,一个Survivor区占整个年轻代的1/5

-XX:MaxPermSize=n:设置持久代大小

收集器设置

-XX:+UseSerialGC:设置串行收集器

-XX:+UseParallelGC:设置并行收集器

-XX:+UseParalledlOldGC:设置并行年老代收集器

-XX:+UseConcMarkSweepGC:设置并发收集器

垃圾回收统计信息

-XX:+PrintGC

-XX:+PrintGCDetails

-XX:+PrintGCTimeStamps

-Xloggc:filename

并行收集器设置

-XX:ParallelGCThreads=n:设置并行收集器收集时使用的CPU数。并行收集线程数。

-XX:MaxGCPauseMillis=n:设置并行收集最大暂停时间

-XX:GCTimeRatio=n:设置垃圾回收时间占程序运行时间的百分比。公式为1/(1+n)

并发收集器设置

-XX:+CMSIncrementalMode:设置为增量模式。适用于单CPU情况。

-XX:ParallelGCThreads=n:设置并发收集器年轻代收集方式为并行收集时,使用的CPU数。并行收集线程数。

四、调优总结

年轻代大小选择

响应时间优先的应用:尽可能设大,直到接近系统的最低响应时间限制(根据实际情况选择)。在此种情况下,年轻代收集发生的频率也是最小的。同时,减少到达年老代的对象。

吞吐量优先的应用:尽可能的设置大,可能到达Gbit的程度。因为对响应时间没有要求,垃圾收集可以并行进行,一般适合8CPU以上的应用。

年老代大小选择

响应时间优先的应用:年老代使用并发收集器,所以其大小需要小心设置,一般要考虑并发会话率和会话持续时间等一些参数。如果堆设置小了,可以会造成内存碎片、高回收频率以及应用暂停而使用传统的标记清除方式;如果堆大了,则需要较长的收集时间。最优化的方案,一般需要参考以下数据获得:

并发垃圾收集信息

持久代并发收集次数

传统GC信息

花在年轻代和年老代回收上的时间比例

减少年轻代和年老代花费的时间,一般会提高应用的效率

吞吐量优先的应用:一般吞吐量优先的应用都有一个很大的年轻代和一个较小的年老代。原因是,这样可以尽可能回收掉大部分短期对象,减少中期的对象,而年老代尽存放长期存活对象。

较小堆引起的碎片问题

因为年老代的并发收集器使用标记、清除算法,所以不会对堆进行压缩。当收集器回收时,他会把相邻的空间进行合并,这样可以分配给较大的对象。但是,当堆空间较小时,运行一段时间以后,就会出现“碎片”,如果并发收集器找不到足够的空间,那么并发收集器将会停止,然后使用传统的标记、清除方式进行回收。如果出现“碎片”,可能需要进行如下JVM参数配置:

-XX:+UseCMSCompactAtFullCollection:使用并发收集器时,开启对年老代的压缩。

-XX:CMSFullGCsBeforeCompaction=0:上面配置开启的情况下,这里设置多少次Full GC后,对年老代进行压缩

JVM的内存限制

 以上就是详解JVM参数调优技巧总结的内容,更多相关内容请关注PHP中文网(www.php.cn)!

このウェブサイトの声明
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。

ホットAIツール

Undresser.AI Undress

Undresser.AI Undress

リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover

AI Clothes Remover

写真から衣服を削除するオンライン AI ツール。

Undress AI Tool

Undress AI Tool

脱衣画像を無料で

Clothoff.io

Clothoff.io

AI衣類リムーバー

AI Hentai Generator

AI Hentai Generator

AIヘンタイを無料で生成します。

ホットツール

メモ帳++7.3.1

メモ帳++7.3.1

使いやすく無料のコードエディター

SublimeText3 中国語版

SublimeText3 中国語版

中国語版、とても使いやすい

ゼンドスタジオ 13.0.1

ゼンドスタジオ 13.0.1

強力な PHP 統合開発環境

ドリームウィーバー CS6

ドリームウィーバー CS6

ビジュアル Web 開発ツール

SublimeText3 Mac版

SublimeText3 Mac版

神レベルのコード編集ソフト(SublimeText3)

非常に実用的な分散型 JVM 監視ツールです。 非常に実用的な分散型 JVM 監視ツールです。 Aug 15, 2023 pm 05:15 PM

このプロジェクトは、開発者が複数のリモート ホスト JVM をより速く監視できるように設計されています。プロジェクトが Spring Boot の場合、統合は非常に簡単です。jar パッケージを導入するだけです。Spring Boot でない場合でも、落胆する必要はありません。 Spring Boot プログラムを手早く初期化し、自分で導入する Jar パッケージで十分です

JVM コマンドラインパラメータの詳細説明: JVM の動作を制御する秘密兵器 JVM コマンドラインパラメータの詳細説明: JVM の動作を制御する秘密兵器 May 09, 2024 pm 01:33 PM

JVM コマンド ライン パラメータを使用すると、JVM の動作をきめ細かいレベルで調整できます。共通パラメータは次のとおりです。 Java ヒープ サイズの設定 (-Xms、-Xmx) 新しい世代サイズの設定 (-Xmn) パラレル ガベージ コレクタの有効化 (-XX:+UseParallelGC) Survivor 領域のメモリ使用量の削減 (-XX: -ReduceSurvivorSetInMemory) 冗長性の削除 ガベージ コレクションの削除 (-XX:-EliminateRedundantGCs) ガベージ コレクション情報の印刷 (-XX:+PrintGC) G1 ガベージ コレクターの使用 (-XX:-UseG1GC) ガベージ コレクションの最大休止時間の設定 (-XX:MaxGCPau)

JVM仮想マシンの機能と原理の分析 JVM仮想マシンの機能と原理の分析 Feb 22, 2024 pm 01:54 PM

JVM 仮想マシンの機能と原理の分析の紹介: JVM (JavaVirtualMachine) 仮想マシンは、Java プログラミング言語の中核コンポーネントの 1 つであり、Java の最大のセールス ポイントの 1 つです。 JVM の役割は、Java ソース コードをバイトコードにコンパイルし、これらのバイトコードを実行することです。この記事では、JVM の役割とその仕組みを紹介し、読者の理解を深めるためにいくつかのコード例を示します。機能: JVM の主な機能は、さまざまなプラットフォーム上での Java プログラムの移植性の問題を解決することです。

JVMメモリ管理のポイントと注意事項 JVMメモリ管理のポイントと注意事項 Feb 20, 2024 am 10:26 AM

JVM のメモリ使用量を使いこなすためのポイントと注意点 JVM (JavaVirtualMachine) は Java アプリケーションが動作する環境であり、最も重要なのは JVM のメモリ管理です。 JVM メモリを適切に管理すると、アプリケーションのパフォーマンスが向上するだけでなく、メモリ リークやメモリ オーバーフローなどの問題も回避できます。この記事では、JVM メモリ使用の重要なポイントと考慮事項を紹介し、いくつかの具体的なコード例を示します。 JVM メモリ パーティション JVM メモリは主に次の領域に分割されます。 ヒープ (ヒープ)

JVM が 32 ビットか 64 ビットかを確認する Java プログラム JVM が 32 ビットか 64 ビットかを確認する Java プログラム Sep 05, 2023 pm 06:37 PM

JVM が 32 ビットか 64 ビットかを確認する Java プログラムを作成する前に、まず JVM について説明します。 JVM は Java 仮想マシンであり、バイトコードの実行を担当します。これは Java ランタイム環境 (JRE) の一部です。 Java はプラットフォームに依存しませんが、JVM はプラットフォームに依存することは誰もが知っています。オペレーティング システムごとに個別の JVM が必要です。 Java ソース コードのバイトコードがあれば、JVM により任意のプラットフォームで簡単に実行できます。 Java ファイル実行のプロセス全体は次のとおりです。まず、Java ソース コードを .java 拡張子で保存し、コンパイラがそれを .class 拡張子を持つバイトコードに変換します。これはコンパイル時に発生します。さて、実行時に、J

Java エラー: JVM メモリ オーバーフロー エラー、対処方法と回避方法 Java エラー: JVM メモリ オーバーフロー エラー、対処方法と回避方法 Jun 24, 2023 pm 02:19 PM

Java は人気のあるプログラミング言語ですが、Java アプリケーションの開発中に、JVM メモリ オーバーフロー エラーが発生する場合があります。通常、このエラーによりアプリケーションがクラッシュし、ユーザー エクスペリエンスに影響を与えます。この記事では、JVM メモリ オーバーフロー エラーの原因と、そのようなエラーに対処および回避する方法について説明します。 JVMメモリオーバーフローエラーとは何ですか? Java 仮想マシン (JVM) は、Java アプリケーションの実行環境です。 JVM では、メモリはヒープ、メソッド領域、スタックなどの複数の領域に分割されます。ヒープは作成されたオブジェクトを保存するために使用されます

jvm のガベージ コレクション メカニズムとは何ですか? jvm のガベージ コレクション メカニズムとは何ですか? Feb 01, 2023 pm 02:02 PM

jvm のガベージ コレクション メカニズムは GC (Garbage Collection) であり、ガベージ コレクターとも呼ばれます。 GC の基本原理: メモリ内で使用されなくなったオブジェクトをリサイクルします。GC でリサイクルする方法はコレクターと呼ばれます。GC はある程度のリソースと時間を消費する必要があるため、Java はオブジェクトのライフサイクル特性を分析し、オブジェクトに従います。アプリケーションへの GC による一時停止をできるだけ短くするために、新世代と旧世代で収集されます。

Linux 上の Tomcat8 で JVM メモリ構成を変更する方法 Linux 上の Tomcat8 で JVM メモリ構成を変更する方法 Jun 03, 2023 am 08:43 AM

Tomcat8 で JVM メモリ設定を変更する方法 Tomcat では、変数を catalina.sh に直接設定することを推奨せず、catalina と同じディレクトリ (bin ディレクトリ) にある setenv.sh に変数を書き込むことを推奨しています。したがって、jvm のメモリ構成を変更したい場合は、setenv.sh ファイルを変更し (デフォルトではなく、新しい setenv.sh を作成する必要があります)、書き込みます (状況に応じてサイズを変更します)。 :exportCATALINA_OPTS="$CATALINA_OPTS-Xms1000m"exportCATALINA_OPTS="$CATALINA

See all articles