应用：shark-新美台移动端网络优化(每天移动端请求约150亿韩元)应用功能：
Qps比较高，新生代增长较快的用户的连接需要保持一段时间的独立期，数十万以上的三个特征导致大量小个体聚集在old区，高峰期old区增长非常快，个体只能在一段时间内消亡。(威廉莎士比亚，《北方司法》前情提要)。
早期的在线GC包括
相应的JVM参数包括
-
Xms10g
-
Xmx10g
-
Xss512k
-XX:
PermSize
=
384米
-XX:
MaxPermSize
=
384米
-XX:
纽西兹
=
7g
-XX:
最大新大小
=
7g
-XX:
SurvivorRatio
=
8
-XX:
MaxDirectMemorySize
=
4g
-XX:
UseParNewGC
-XX:
ParallelGCThreads
=
4
-XX:
MaxTenuringThreshold
=
9
-XX:
UseConcMarkSweepGC
-XX:
DisableExplicitGC
-XX:
UseCMSInitiatingOccupancyOnly
-XX:
ScavengeBeforeFullGC
-XX:
UseCMSCompactAtFullCollection
-XX:
CMSParallelRemarkEnabled
-XX:
CMSFullGCsBeforeCompaction
=
9
-XX:
CMSInitiatingOccupancyFraction
=
70
新一代7G (Survivor为2 * 700米)，老年一代3G，个体年龄为9 (new地区进入old地区的速度太快，old地区很快爆满，经常可以看到old GC)。我这边的对象在一段时间(几分钟)内。
第一次调谐
把年龄调整到无限，增加young区。
相应的JVM参数包括
-
Xms14g
-
Xmx14g
-
Xss512k
-XX:
PermSize
=
384米
-XX:
MaxPermSize
=
384米
-XX:
纽西兹
=
12g
-XX:
最大新大小
=
12g
-XX:
SurvivorRatio
=
18
-XX:
MaxDirectMemorySize
=
2g
-XX:
UseParNewGC
-XX:
ParallelGCThreads
=
4
-XX:
MaxTenuringThreshold
=
30
-XX:
UseConcMarkSweepGC
-XX:
DisableExplicitGC
-XX:
UseCMSInitiatingOccupancyOnly
-XX:
ScavengeBeforeFullGC
-XX:
UseCMSCompactAtFullCollection
-XX:
CMSParallelRemarkEnabled
-XX:
CMSFullGCsBeforeCompaction
=
9
-XX:
CMSInitiatingOccupancyFraction
=
70
-XX:
CMSClassUnloadingEnabled
-XX:
SoftRefLRUPolicyMSPerMB
=
0
-XX:-
ReduceInitialCardMarks
-XX:
CMSPermGenSweepingEnabled
-XX:
CMSINITIATINGPERMOCCUPANCYFRACTION
=
70
结果old区域一直空着，但Yong GC时间长了很多，每次平均需要0.2s的时间，比以前的new GC多3倍，无法接受。(威廉莎士比亚，《北方司法》前情提要)。
设置信息-xx3360 maxtenuringthreshold大于15，在jdk1.7版本之前显示为无穷大，无论以后的设置如何，如果大于15，jdk1.8之后的15，则直接报告错误
见面
第二次调谐
再次调整XX:MaxTenuringThreshold，使其最大值为15 (15以上，即对象长寿)。因为以前的CMS在old GC上花费了更多的时间，所以在这里尝试的是serial old
相应的JVM参数包括
-
Xms14g
-
Xmx14g
-
Xss512k
-XX:
PermSize
=
384米
-XX:
MaxPermSize
=
384米
-XX:
纽西兹
=
12g
-XX:
最大新大小
=
12g
-XX:
SurvivorRatio
=
18
-XX:
MaxDirectMemorySize
=
2g
-XX:
UseParNewGC
-XX:
ParallelGCThreads
=
4
-XX:
MaxTenuringThreshold
=
15
发现效果确实很明显。new GC的时间减少了一倍左右，old GC的时间也从原来的15，000毫秒减少到了1500毫秒。(威廉莎士比亚，《北方司法》前情提要)。
第三次调谐
详细研究了第二种调谐方法的组合。我们详细研究了Yong区域使用parNew的方式，以及old区域使用串行old的方式。如果在其他条件都相同的条件下使用parNew CMS，old GC的时间会不会大大缩短？毕竟CMS是比较先进的收集器，所以分析了CMS的不同阶段。两个阶段是stop the world，一个是初始化标记，另一个是重复标记(CMS remark)，重复标记是从CMS old GC开始的那一刻开始的。
查看Gc日志时，查找remark需要很长时间，日志上下文如下
{heapbefore GC invocations=23679(池18) :
Par new generation total 6606080k，used 5902124k[0x 0000000568000000、0x 0000007280000、0x 000000072800000]
Edenspace 5872128k，99% used [0x000000056800000，0x00000006 ce54f，988,0x0000006 ce 680000
From space 733952k，4% used [0x0000006 fb340000、0x 0000006 FD 1bb 758，0x 0000007280000]
To space 733952k，0% used [0x0000006 ce 680000、0x0000006 ce 680000、0x0000006 FB 340000
concurrent mark-sweep generation total 3145728k，used 2200878k[0x 00000728000000，8000000,0x0000007e，0x 0000007 e]
concurrent-mark-sweep perm gen total 393216k，used 37361k [0x00000007e 8000000、0x00000008000000、0x0000000000000000、0x000000080000000
2016-08-27t 17336026:00.058 08003360 261980.413:[GC 2016-08-27t 17336026336000.058 08003360 261980.4 6080k]
Heapafter GC invocations=23680(全部18) :
Par new generation total 6606080k，used 27858k [0x0000000568000000、0x00000007280000、0x00000007280000、0x 00000007280000]
Edenspace 5872128k，0% used [0x0000000568000000、0x000000056800000、0x00000006 ce 680000
From space 733952k，3% used [0x0000006 ce 680000、0x00000006 d01b，0x 0000006 FB 340000]
To space 733952k，0% used [0x0000006 fb340000、0x0000006 fb340000、0x00000072800000
concurrent mark-sweep generation total 3145728k，used 2202742k [0x000000728000000、0x0000007e 8000000、0x0000007e
concurrent-mark-sweep perm gen total 393216k、used 37361k
}
2016-08-27t 17336026:00 . 107 08003360 261980 . 462:应用程序时间3360 0.0014750次要
2016-08-27t 17336026336000.108 08003360 261980.463:[GC[1 CMS-INITI A L-MARK 3360 2202742K(3145728K)]
2016-08-27t 17336026:00.165 08003360 261980.5203360[CMS-CONCURRENT-MARK-START]
2016-08-27t 17336026:00.918 08003360 261981.27:[CMS-CONCURRENT-MARK 3360.753 SECS][TIMES 3360]
2016-08-27t 17336026:00.918 08003360 261981.27:[CMS-CONCURRENT-PRECLEAN-START]
2016-08-27t 17336026:00.949 08003360 261981.3043360[CMS-CONCURRENT-PRECLEAN 3360.028 SECS][时间
2016-08-27t 17336026:00.949 08003360 261981.3043360[CMS-CONCURRENT-ABORT ABLE-PRECLEAN-START]
CMS : abort pre clean due to time 2016-08-27t 17:26:06.159 08003360 261986.5143360[CMS-concurrent-abort]
2016-08-27t 17336026:06.160 08003360 261986.515: application time 3360 5.9951640 seconds
2016-08-27t 17336026:06.161 08003360 261986.5163360[GC[YG OCCCUPANCY 3360 4756927K(6606080K)]
2016-08-27t 17336026:06.161 08003360 261986.5163360[rescan(parallel)，18.1621480 secs]
2016-08-27t 17336026:24.323 08003360 262004.6783360[weak refs processing，0.0000750 secs
2016-08-27t 17336026:24.323 08003360 262004.6783360[类unloading，0.0069760 secs
2016-08-27t 17336026:24.330 08003360 262004.6853360
2016-08-27t 17336026336024.334 08003360 262004.6893360 0.0009240 secs][1 CMS-remark 3360 2202742k(3145728k)]
2016-08-27t 17336026336024.338 08002016-08-27t 17336026:24.338 08003360 3360 262004.693360应用时间
262004 . 69:[CMS-concurrent-sweep-start]
2016-08-27t 17336026:24.347 08003360 262004.702:应用程序时间3360 0.0079820第二部分
2016-08-27t 17336026:24.868 08003360 262005.22:应用程序时间3360 0.5186580第二部分
{heapbefore GC invocations=23680(池19) :
Par new generation total 6606080k，used 5899299k [0x000000056800000、0x000000072800000、0x 000000072800000]
Edenspace 5872128k，99% used [0x000000056800000，0x00000006 ce 5d 44b，8,0x0000006 ce 680000
From space 733952k，3% used [0x0000006 ce 680000、0x00000006 d01b，0x 0000006 FB 340000]
To space 733952k，0% used [0x0000006 fb340000、0x0000006 fb340000、0x00000072800000
concurrent mark-sweep generation total 3145728k，used 1891716k
concurrent-mark-sweep perm gen total 393216k、used 37361k
2016-08-27t 17336026336024.870 08003360 262005.2253360[GC 2016-08-27t 17336026336024.870 08003360 262005.270 6080k]
Heapafter GC invocations=23681(全部19) :
Par new generation total 6606080k，used 56108k [0x00000005680000000，0x00000072800000，0x 000000728000000]
Edenspace 5872128k，0% used [0x0000000568000000、0x000000056800000、0x00000006 ce 680000
From space 733952k，7% used [0x0000006 fb340000、0x0000006 fea0b1f8，0 x 0000007280000]
To space 733952k，0% used [0x0000006 ce 680000、0x0000006 ce 680000、0x0000006 FB 340000
concurrent mark-sweep generation total 3145728k，used 1893599k
concurrent-mark-sweep perm gen total 393216k、used 37361k
}
18s(此段落[1 CMS-REMARK 3360 2202742K(3145728K)]6959670K(9751808K)、18.1769610secs])！重新标记时，old区域的大小是固定的(设置为old区域的70%)。remark的时间差不多没错，但是查了很多CMS old GC日志，发现高峰期和低峰值remark的时间差异太大，只有elden区域有差异。因为我在这里。Cms old启动，在remark之间，用户程序与GC线程同时运行。到达remark后，Eden区域中可能已经有很多对象。如果remark能够清理Eden区域的所有对象，remark的对象就会少得多。Google发现CMS有一个名为XX3360 CMSScavengebeforeremark的参数。这是在remark之前来一次Yong GC，以满足我们的需求，并添加此参数后。
相应的JVM参数包括
-
Xms14g
-
Xmx14g
-
Xss512k
-XX:
PermSize
=
384米
-XX:
MaxPermSize
=
384米
-XX:
纽西兹
=
12g
-XX:
最大新大小
=
12g
-XX:
SurvivorRatio
=
18
-XX:
MaxDirectMemorySize
=
2g
-XX:
UseParNewGC
-XX:
ParallelGCThreads
=
4
-XX:
MaxTenuringThreshold
=
15
-XX:
CMSScavengeBeforeRemark
-XX:
UseConcMarkSweepGC
-XX:
DisableExplicitGC
-XX:
UseCMSInitiatingOccupancyOnly
-XX:
ScavengeBeforeFullGC
-XX:
UseCMSCompactAtFullCollection
-XX:
CMSParallelRemarkEnabled
-XX:
CMSFullGCsBeforeCompaction
=
9
-XX:
CMSInitiatingOccupancyFraction
=
70
效果如下
发现Old GC的时间缩小到原来CMS的1/100进行盗窃。
接下来分析gc日志，来验证我的猜想{Heap before GC invocations=4644 (full 6): par new generation total 11953792K, used 11384636K [0x0000000468000000, 0x0000000768000000, 0x0000000768000000) eden space 11324672K, 99% used [0x0000000468000000, 0x000000071b30eb48, 0x000000071b340000) from space 629120K, 9% used [0x000000071b340000, 0x000000071ee004e0, 0x00000007419a0000) to space 629120K, 0% used [0x00000007419a0000, 0x00000007419a0000, 0x0000000768000000) concurrent mark-sweep generation total 2097152K, used 1464467K [0x0000000768000000, 0x00000007e8000000, 0x00000007e8000000) concurrent-mark-sweep perm gen total 393216K, used 37291K [0x00000007e8000000, 0x0000000800000000, 0x0000000800000000) 2016-08-28T10:46:09.846+0800: 68434.688: [GC2016-08-28T10:46:09.846+0800: 68434.688: [ParNew: 11384636K->61763K(11953792K), 0.0716150 secs] 12849103K->1528727K(14050944K), 0.0719060 secs] [Times: user=0.28 sys=0.00, real=0.07 secs] Heap after GC invocations=4645 (full 6): par new generation total 11953792K, used 61763K [0x0000000468000000, 0x0000000768000000, 0x0000000768000000) eden space 11324672K, 0% used [0x0000000468000000, 0x0000000468000000, 0x000000071b340000) from space 629120K, 9% used [0x00000007419a0000, 0x00000007455f0dd8, 0x0000000768000000) to space 629120K, 0% used [0x000000071b340000, 0x000000071b340000, 0x00000007419a0000) concurrent mark-sweep generation total 2097152K, used 1466964K [0x0000000768000000, 0x00000007e8000000, 0x00000007e8000000) concurrent-mark-sweep perm gen total 393216K, used 37291K [0x00000007e8000000, 0x0000000800000000, 0x0000000800000000) } 2016-08-28T10:46:19.590+0800: 68444.431: Application time: 9.6715460 seconds {Heap before GC invocations=4645 (full 6): par new generation total 11953792K, used 11384705K [0x0000000468000000, 0x0000000768000000, 0x0000000768000000) eden space 11324672K, 99% used [0x0000000468000000, 0x000000071b18f768, 0x000000071b340000) from space 629120K, 9% used [0x00000007419a0000, 0x00000007455f0dd8, 0x0000000768000000) to space 629120K, 0% used [0x000000071b340000, 0x000000071b340000, 0x00000007419a0000) concurrent mark-sweep generation total 2097152K, used 1466964K [0x0000000768000000, 0x00000007e8000000, 0x00000007e8000000) concurrent-mark-sweep perm gen total 393216K, used 37291K [0x00000007e8000000, 0x0000000800000000, 0x0000000800000000) 2016-08-28T10:46:19.591+0800: 68444.433: [GC2016-08-28T10:46:19.591+0800: 68444.433: [ParNew: 11384705K->69180K(11953792K), 0.0728020 secs] 12851669K->1538700K(14050944K), 0.0730170 secs] [Times: user=0.27 sys=0.01, real=0.07 secs] Heap after GC invocations=4646 (full 6): par new generation total 11953792K, used 69180K [0x0000000468000000, 0x0000000768000000, 0x0000000768000000) eden space 11324672K, 0% used [0x0000000468000000, 0x0000000468000000, 0x000000071b340000) from space 629120K, 10% used [0x000000071b340000, 0x000000071f6cf378, 0x00000007419a0000) to space 629120K, 0% used [0x00000007419a0000, 0x00000007419a0000, 0x0000000768000000) concurrent mark-sweep generation total 2097152K, used 1469519K [0x0000000768000000, 0x00000007e8000000, 0x00000007e8000000) concurrent-mark-sweep perm gen total 393216K, used 37291K [0x00000007e8000000, 0x0000000800000000, 0x0000000800000000) } 2016-08-28T10:46:19.666+0800: 68444.508: Application time: 0.0019110 seconds 2016-08-28T10:46:19.667+0800: 68444.509: [GC [1 CMS-initial-mark: 1469519K(2097152K)] 1545525K(14050944K), 0.0869600 secs] [Times: user=0.09 sys=0.00, real=0.08 secs] 2016-08-28T10:46:19.755+0800: 68444.597: [CMS-concurrent-mark-start] 2016-08-28T10:46:20.418+0800: 68445.260: [CMS-concurrent-mark: 0.663 secs] [Times: user=1.47 sys=0.24, real=0.66 secs] 2016-08-28T10:46:20.418+0800: 68445.260: [CMS-concurrent-preclean-start] 2016-08-28T10:46:20.438+0800: 68445.280: [CMS-concurrent-preclean: 0.018 secs] [Times: user=0.04 sys=0.01, real=0.02 secs] 2016-08-28T10:46:20.438+0800: 68445.280: [CMS-concurrent-abortable-preclean-start] 2016-08-28T10:46:24.542+0800: 68449.384: [CMS-concurrent-abortable-preclean: 4.090 secs] [Times: user=8.60 sys=1.40, real=4.10 secs] 2016-08-28T10:46:24.543+0800: 68449.385: Application time: 4.7880220 seconds // 这里在remark之前进行一次young gc ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝yong gc开始＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ 2016-08-28T10:46:24.544+0800: 68449.386: [GC[YG occupancy: 5803756 K (11953792 K)]{Heap before GC invocations=4646 (full 7): par new generation total 11953792K, used 5803756K [0x0000000468000000, 0x0000000768000000, 0x0000000768000000) eden space 11324672K, 50% used [0x0000000468000000, 0x00000005c602bd88, 0x000000071b340000) from space 629120K, 10% used [0x000000071b340000, 0x000000071f6cf378, 0x00000007419a0000) to space 629120K, 0% used [0x00000007419a0000, 0x00000007419a0000, 0x0000000768000000) concurrent mark-sweep generation total 2097152K, used 1469519K [0x0000000768000000, 0x00000007e8000000, 0x00000007e8000000) concurrent-mark-sweep perm gen total 393216K, used 37291K [0x00000007e8000000, 0x0000000800000000, 0x0000000800000000) 2016-08-28T10:46:24.544+0800: 68449.386: [GC2016-08-28T10:46:24.544+0800: 68449.386: [ParNew: 5803756K->70533K(11953792K), 0.0668770 secs] 7273276K->1542365K(14050944K), 0.0669610 secs] [Times: user=0.25 sys=0.01, real=0.07 secs] Heap after GC invocations=4647 (full 7): par new generation total 11953792K, used 70533K [0x0000000468000000, 0x0000000768000000, 0x0000000768000000) eden space 11324672K, 0% used [0x0000000468000000, 0x0000000468000000, 0x000000071b340000) from space 629120K, 11% used [0x00000007419a0000, 0x0000000745e81738, 0x0000000768000000) to space 629120K, 0% used [0x000000071b340000, 0x000000071b340000, 0x00000007419a0000) concurrent mark-sweep generation total 2097152K, used 1471831K [0x0000000768000000, 0x00000007e8000000, 0x00000007e8000000) concurrent-mark-sweep perm gen total 393216K, used 37291K [0x00000007e8000000, 0x0000000800000000, 0x0000000800000000) } ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝yong gc结束,开始remark＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ 2016-08-28T10:46:24.611+0800: 68449.453: [Rescan (parallel) , 0.0392690 secs] 2016-08-28T10:46:24.650+0800: 68449.492: [weak refs processing, 0.0001190 secs 2016-08-28T10:46:24.650+0800: 68449.492: [class unloading, 0.0072200 secs] 2016-08-28T10:46:24.658+0800: 68449.500: [scrub symbol table, 0.0083430 secs] 2016-08-28T10:46:24.666+0800: 68449.508: [scrub string table, 0.0011760 secs] [1 CMS-remark: 1471831K(2097152K)] 1542365K(14050944K), 0.1264420 secs] [Times: user=0.42 sys=0.01, real=0.13 secs] 2016-08-28T10:46:24.671+0800: 68449.513: [CMS-concurrent-sweep-start] 2016-08-28T10:46:24.672+0800: 68449.514: Application time: 0.0018070 seconds 2016-08-28T10:46:26.388+0800: 68451.230: [CMS-concurrent-sweep: 1.714 secs] [Times: user=3.70 sys=0.58, real=1.72 secs] 2016-08-28T10:46:26.388+0800: 68451.230: [CMS-concurrent-reset-start] 2016-08-28T10:46:26.396+0800: 68451.238: [CMS-concurrent-reset: 0.007 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] 2016-08-28T10:46:34.434+0800: 68459.276: Application time: 9.7600810 seconds可以看到，在remark之前，来一次yong gc，eden区域从50%降到0(总大小为10.8G)，这些空间如果不消除，那么cms将会在这些空间上进行非常耗时的标记，最后再看看remark的时间（[1 CMS-remark: 1471831K(2097152K)] 1542365K(14050944K), 0.1264420 secs]），降到0.1264420s，和原来相比，整整一百倍的提高。
总结：
最后，对于长连接，push一类的海量服务端应用，16G内存8核心，推荐的JVM参数如下
jdk1.7- Xms13g - Xmx13g - Xss512k -XX: PermSize = 384m -XX: MaxPermSize = 384m -XX: NewSize = 12g -XX: MaxNewSize = 12g -XX: SurvivorRatio = 18 -XX: MaxDirectMemorySize = 2g -XX:+ UseParNewGC -XX: ParallelGCThreads = 4 -XX: MaxTenuringThreshold = 15 -XX:+ CMSParallelRemarkEnabled -XX:+ CMSScavengeBeforeRemark -XX:+ UseConcMarkSweepGC -XX:+ DisableExplicitGC -XX:+ UseCMSInitiatingOccupancyOnly -XX: CMSInitiatingOccupancyFraction = 70 -XX:+ ScavengeBeforeFullGC -XX:+ UseCMSCompactAtFullCollection -XX: CMSFullGCsBeforeCompaction = 9 -XX:+ CMSClassUnloadingEnabled -XX: CMSInitiatingPermOccupancyFraction = 70 -XX:+ ExplicitGCInvokesConcurrent -XX:+ PrintGCDetails -XX:+ PrintGCDateStamps -XX:+ PrintGCApplicationConcurrentTime -XX:+ PrintHeapAtGC - Xloggc : /data/ applog -XX:- HeapDumpOnOutOfMemoryError -XX: HeapDumpPath = /data/ applogs/ HeapDumpOnOutOfMemoryError
jdk1.8- Xms13g - Xmx13g - Xss512k -XX: MetaspaceSize = 384m -XX: MaxMetaspaceSize = 384m -XX: NewSize = 11g -XX: MaxNewSize = 11g -XX: SurvivorRatio = 18 -XX: MaxDirectMemorySize = 2g -XX:+ UseParNewGC -XX: ParallelGCThreads = 4 -XX: MaxTenuringThreshold = 15 -XX:+ UseConcMarkSweepGC -XX:+ DisableExplicitGC -XX:+ UseCMSInitiatingOccupancyOnly -XX:+ ScavengeBeforeFullGC -XX:+ CMSScavengeBeforeRemark -XX:+ CMSParallelRemarkEnabled -XX: CMSInitiatingOccupancyFraction = 70 -XX:+ CMSClassUnloadingEnabled -XX: SoftRefLRUPolicyMSPerMB = 0 -XX:- ReduceInitialCardMarks -XX:+ CMSClassUnloadingEnabled -XX:+ ExplicitGCInvokesConcurrent -XX:+ PrintGCDetails -XX:+ PrintGCDateStamps -XX:+ PrintGCApplicationConcurrentTime -XX:+ PrintHeapAtGC - Xloggc : /data/ applog -XX:- HeapDumpOnOutOfMemoryError -XX: HeapDumpPath = /data/ applogs/ HeapDumpOnOutOfMemoryError "
这样可以保证大多数对象在new区域就销毁，并且到了old区，remark之前先yong gc，然后再来一次cms old gc，将old gc控制在毫秒级别
如果你觉得看的不过瘾，想系统学习Netty原理，那么你一定不要错过我的Netty源码分析系列视频：
转自公众号：闪电侠的博客
1.《678改动日志看这里!百万连接，百亿吞吐量服务的JVM性能调优实战》援引自互联网，旨在传递更多网络信息知识，仅代表作者本人观点，与本网站无关，侵删请联系页脚下方联系方式。
2.《678改动日志看这里!百万连接，百亿吞吐量服务的JVM性能调优实战》仅供读者参考，本网站未对该内容进行证实，对其原创性、真实性、完整性、及时性不作任何保证。
3.文章转载时请保留本站内容来源地址，https://www.lu-xu.com/gl/2081163.html
