海量连接服务端jvm参数调优杂记

原创作品,转载须标明出处自:

利用:shark-新美大活动端网络优化(每一日接受移动端请求约50亿)

http://www.cnblogs.com/gisspace/p/8269525.html

选拔特点:

  1. qps相比较高,新生代增长迅速
  2. 用户的接连需要保障一段时间
  3. 单机需要保障海量连接,几十万的级别

上述五个特色导致有雅量小目的聚集在old区,高峰期old区域加强十分快,对象在一段时间内必将会化为乌有


起始的线上gc的情况如下

对应的jvm参数为

-Xms10g -Xmx10g -Xss512k -XX:PermSize=384m -XX:MaxPermSize=384m -XX:NewSize=7g -XX:MaxNewSize=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*700M),老年代为3G,对象年龄依然唯有9(导致new
区域进入到old区域的快慢太快,old区域急忙被撑满,频繁old
gc),考虑到自我这边的目的在一段时间内(几分钟)肯定会破灭,于是先举办四回调优尝试


率先次调优

将年龄调成无穷,调大young区

对应的jvm参数为

-Xms14g -Xmx14g -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=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多了总体三倍,是力不从心经受的


2017.09.22翻新
关于设置-XX:马克斯TenuringThreshold大于15,在jdk1.7某部版本此前表示是无穷大,之后不管设置成多少,都是15,jdk1.8事后大于15直接报错

http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2008-May/000309.html

小说目录

第二次调优

将XX:马克斯TenuringThreshold调整回来,调整成最大的值15(大于15即对象长命百岁),由于事先cms
在old gc花的时间相比多,所以那边品尝的serial old

对应的jvm参数为

-Xms14g -Xmx14g -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

察觉效能实在相比较显然,new gc的流年压缩了两倍左右,并且old
gc的岁月也从原来的15000ms 裁减到1500ms

|– 1. 新建共享目录

其三回调优

仔细钻探了一下次之种调优模式的构成,yong区域采取parNew
的法门,old区域动用serial old
的章程,假若在其余规格都一模一样的基准下采纳parNew+cms的艺术,old
gc的年月会不会大幅度缩水?毕竟cms依旧相比提升的收集器,于是分析了一下cms的多少个等级,有五个级次是stop
the world的,一个是先导化标记(intial mark),一个是重复标记(cms
remark),重复标记的原委是从cms old
gc开端的那一刻到起来解除可能过多目的的情景都发出了转变,所以这个时候需要暂停用户所有的线程,来一次标记再清除

查看gc日志,发现remark的时间相比长,日志上下文如下

{Heap before GC invocations=23679 (full 18):
par new generation   total 6606080K, used 5902124K [0x0000000568000000, 0x0000000728000000, 0x0000000728000000)
eden space 5872128K,  99% used [0x0000000568000000, 0x00000006ce54f988, 0x00000006ce680000)
from space 733952K,   4% used [0x00000006fb340000, 0x00000006fd1bb758, 0x0000000728000000)
to   space 733952K,   0% used [0x00000006ce680000, 0x00000006ce680000, 0x00000006fb340000)
concurrent mark-sweep generation total 3145728K, used 2200878K [0x0000000728000000, 0x00000007e8000000, 0x00000007e8000000)
concurrent-mark-sweep perm gen total 393216K, used 37361K [0x00000007e8000000, 0x0000000800000000, 0x0000000800000000)
2016-08-27T17:26:00.058+0800: 261980.413: [GC2016-08-27T17:26:00.058+0800: 261980.413: [ParNew: 5902124K->27858K(6606080K), 0.0464930 secs] 8103002K->2230601K(9751808K), 0.0468010 secs] [Times: user=0.18 sys=0.00, real=0.05 secs]
Heap after GC invocations=23680 (full 18):
par new generation   total 6606080K, used 27858K [0x0000000568000000, 0x0000000728000000, 0x0000000728000000)
eden space 5872128K,   0% used [0x0000000568000000, 0x0000000568000000, 0x00000006ce680000)
from space 733952K,   3% used [0x00000006ce680000, 0x00000006d01b4910, 0x00000006fb340000)
to   space 733952K,   0% used [0x00000006fb340000, 0x00000006fb340000, 0x0000000728000000)
concurrent mark-sweep generation total 3145728K, used 2202742K [0x0000000728000000, 0x00000007e8000000, 0x00000007e8000000)
concurrent-mark-sweep perm gen total 393216K, used 37361K [0x00000007e8000000, 0x0000000800000000, 0x0000000800000000)
}
2016-08-27T17:26:00.107+0800: 261980.462: Application time: 0.0014750 seconds
2016-08-27T17:26:00.108+0800: 261980.463: [GC [1 CMS-initial-mark: 2202742K(3145728K)] 2235571K(9751808K), 0.0561400 secs] [Times: user=0.05 sys=0.00, real=0.05 secs]
2016-08-27T17:26:00.165+0800: 261980.520: [CMS-concurrent-mark-start]
2016-08-27T17:26:00.918+0800: 261981.273: [CMS-concurrent-mark: 0.753/0.754 secs] [Times: user=1.27 sys=0.12, real=0.76 secs]
2016-08-27T17:26:00.918+0800: 261981.273: [CMS-concurrent-preclean-start]
2016-08-27T17:26:00.949+0800: 261981.304: [CMS-concurrent-preclean: 0.028/0.031 secs] [Times: user=0.04 sys=0.01, real=0.03 secs]
2016-08-27T17:26:00.949+0800: 261981.304: [CMS-concurrent-abortable-preclean-start]
CMS: abort preclean due to time 2016-08-27T17:26:06.159+0800: 261986.514: [CMS-concurrent-abortable-preclean: 5.197/5.210 secs] [Times: user=8.31 sys=0.66, real=5.21 secs]
2016-08-27T17:26:06.160+0800: 261986.515: Application time: 5.9951640 seconds
2016-08-27T17:26:06.161+0800: 261986.516: [GC[YG occupancy: 4756927 K (6606080 K)]2016-08-27T17:26:06.161+0800: 261986.516: [Rescan (parallel) , 18.1621480 secs]2016-08-27T17:26:24.323+0800: 262004.678: [weak refs processing, 0.0000750 secs]2016-08-27T17:26:24.323+0800: 262004.678: [class unloading, 0.0069760 secs]2016-08-27T17:26:24.330+0800: 262004.685: [scrub symbol table, 0.0040020 secs]2016-08-27T17:26:24.334+0800: 262004.689: [scrub string table, 0.0009240 secs] [1 CMS-remark: 2202742K(3145728K)] 6959670K(9751808K), 18.1769610 secs] [Times: user=71.37 sys=0.06, real=18.18 secs]
2016-08-27T17:26:24.338+08002016-08-27T17:26:24.338+0800: : 262004.693: Application time: 0.0002080 seconds
262004.693: [CMS-concurrent-sweep-start]
2016-08-27T17:26:24.347+0800: 262004.702: Application time: 0.0079820 seconds
2016-08-27T17:26:24.868+0800: 262005.223: Application time: 0.5186580 seconds
{Heap before GC invocations=23680 (full 19):
par new generation   total 6606080K, used 5899299K [0x0000000568000000, 0x0000000728000000, 0x0000000728000000)
eden space 5872128K,  99% used [0x0000000568000000, 0x00000006ce5d44b8, 0x00000006ce680000)
from space 733952K,   3% used [0x00000006ce680000, 0x00000006d01b4910, 0x00000006fb340000)
to   space 733952K,   0% used [0x00000006fb340000, 0x00000006fb340000, 0x0000000728000000)
concurrent mark-sweep generation total 3145728K, used 1891716K [0x0000000728000000, 0x00000007e8000000, 0x00000007e8000000)
concurrent-mark-sweep perm gen total 393216K, used 37361K [0x00000007e8000000, 0x0000000800000000, 0x0000000800000000)
2016-08-27T17:26:24.870+0800: 262005.225: [GC2016-08-27T17:26:24.870+0800: 262005.225: [ParNew: 5899299K->56108K(6606080K), 0.0580910 secs] 7791015K->1949708K(9751808K), 0.0584000 secs] [Times: user=0.22 sys=0.01, real=0.05 secs]
Heap after GC invocations=23681 (full 19):
par new generation   total 6606080K, used 56108K [0x0000000568000000, 0x0000000728000000, 0x0000000728000000)
eden space 5872128K,   0% used [0x0000000568000000, 0x0000000568000000, 0x00000006ce680000)
from space 733952K,   7% used [0x00000006fb340000, 0x00000006fea0b1f8, 0x0000000728000000)
to   space 733952K,   0% used [0x00000006ce680000, 0x00000006ce680000, 0x00000006fb340000)
concurrent mark-sweep generation total 3145728K, used 1893599K [0x0000000728000000, 0x00000007e8000000, 0x00000007e8000000)
concurrent-mark-sweep perm gen total 393216K, used 37361K [0x00000007e8000000, 0x0000000800000000, 0x0000000800000000)
}

双重标记居然用了18s(这一段[1 CMS-remark: 2202742K(3145728K)]
6959670K(9751808K), 18.1769610
secs]
)!重新标记的时候,old区域的尺寸是一定的(这里安装成old区域的70%),按理说每一趟remark的时日应当都差不多才对,不过查了众多cms
old
gc日志,发现高峰期和低峰期remark的光阴相差太大,两者的分别也唯有elden区域,因为自己这边elden的装置是比较大的,高峰期的时候,五次cms
old最先,到remark之间这段时日,用户程序会和gc线程同步执行,到remark的时候,eden区很可能早已有雅量对象了,固然remark往日能把eden区域的靶子都清理几次,这remark的对象将会少很多过多对吧?google了一把,发现cms有这么个参数-XX:+CMSScavengeBeforeRemark,这玩意儿的意趣是在remark在此之前,来五遍yong
gc,满意我们的要求,加了这多少个参数之后

对应的jvm参数为

 -Xms14g -Xmx14g -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:+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/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/0.020 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/4.104 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/1.717 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/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,和原来相比,整整一百倍的增高。

|– 2. 成立站点

总结:

末段,对于长连接,push一类的雅量服务端应用,16G内存8主旨,推荐的JVM参数如下
2017.06.28更新
jdk 1.7 14g->13g

-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/applogs/heap_trace.txt -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/applogs/heap_trace.txt -XX:-HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/applogs/HeapDumpOnOutOfMemoryError"

这么可以确保大多数目的在new区域就销毁,并且到了old区,remark从前先yong
gc,然后再来两遍cms old gc,将old gc控制在毫秒级别

|– 3. 参加集群

|– 4. Web 艾达ptor实现负载均衡


 

单机版本的ArcGIS
Server负载能力简单,当站点的服务访问量抢先一定数量的时候,单机站点无法知足服务需要,这时候就需要树立集群来充实所有站点的载荷能力。

 

1. 新建共享目录

  为了共同集群中各种总括机的站点状态,ArcGIS
Server站点的config-store目录和directories目录必须能被集群中享有电脑的arcgis
server account用户访问。

  共享目录最好独立于集群中的任何一台微机,这样在单台总括机暴发故障的时候也不会映像站点其他计量的运行。

  假使共享目录在集群中某一台电脑上,这台电脑暴发故障需要重启时,则面临尴尬的程度!重启总结机会影响所有站点,不重启又解决不了故障。

  下边以Windows Server 2008R2 SP1为例,创制共享目录。

  Step1:在文件服务器上新建arcgis server account

    此用户与安装arcgis
server时创制的用户须一致,以管教集群中的统计机均可访问。

    起初–>管理工具–>总括机管理

    澳门美高梅手机网站 1

    找到“本地用户和组”,右键“用户”新建用户

    澳门美高梅手机网站 2

    输入用户音讯,与安装arcgis server时成立的用户同样

    澳门美高梅手机网站 3

    完成成立用户完成。

  Step2:创建config-store目录和directories目录,并共享,确保arcgis
server account用户拥有读写权限

    新建目录arcgisserver,创建六个子目录config-store、directories

    右键arcgisserver文件夹,属性–>共享,添加arcgis用户,并给予读写权限

     澳门美高梅手机网站 4

    完成新建共享目录!

 

2. 开立站点

澳门美高梅手机网站,  步骤同Windows下创建ArcGIS
Server站点

  不同的是,在指定config-store目录和directories目录时须指向共享目录。

  假诺是现有站点,则修改config-store目录和directories目录为共享目录。

 

3. 参加集群

  集群中逐条总括机的操作系统版本须一致

  在新电脑上设置与存活站点版本相同的ArcGIS Server
,安装时采纳同样的arcgis server account配置文件

  完成安装!打开https://localhost:6443/arcgis/manager(建议使用Chrome,如果使用IE则须升级到IE11),选择“加入现有站点”

  澳门美高梅手机网站 5

  指定已有站点url,输入管理员用户名(默认siteadmin)、密码

  澳门美高梅手机网站 6

  完成布置,等待进入站点

  澳门美高梅手机网站 7

  成功进入站点后会跳转到ArcGIS Server
Manager登录界面,输入管理员用户名、密码

  澳门美高梅手机网站 8

  登录后,点击“站点”–>“集群”,即可查看到电脑已加盟站点

  澳门美高梅手机网站 9

  到这边,ArcGIS Server站点集群已经建立成功。

 

4. Web 艾达ptor实现负载均衡

  此时,向站点内的另外总括机宣布服务,均可透过其它统计机访问。

  可是在应用劳务时,若是如故访问单个总计机的劳动地点,则尚未加强劳动的载荷能力。

  此时亟待一个载重均衡器来增援我们分担请求流量至集群中的各台总括机。

  实现负载均衡的方法很多,我们这边运用ESRI提供的Web 艾达(Ada)ptor for IIS。 

  Step1:开启IIS

    打开服务器管理器,采取角色–>添加角色

    澳门美高梅手机网站 10

    澳门美高梅手机网站 11

    选择“Web 服务器(IIS)”

    澳门美高梅手机网站 12

    澳门美高梅手机网站 13

    澳门美高梅手机网站 14

    ArcGIS Web Adaptor for IIS需要相当勾选以下服务

    澳门美高梅手机网站 15澳门美高梅手机网站 16澳门美高梅手机网站 17

    成功开启IIS!

    澳门美高梅手机网站 18

  Step2:安装Web Adaptor

    双击安装文件,假如紧缺IIS相关服务,安装向导会指示缺失。

    已启动IIS则能进入下一步安装

    这里会提示是否安装Silverlight和Flex的跨域访问组件,我们由此JavaScript访问,无需安装。

    澳门美高梅手机网站 19

    输入代理名称替换默认的arcgis,如mygis

    澳门美高梅手机网站 20

    完成安装!

  Step3:配置Web Adaptor

    打开“http://localhost/arcgis/webadaptor”,这里的arcgis须替换为安装时你输入的名称

    如“http://localhost/mygis/webadaptor”

     采纳安排“ArcGIS for Server”

     澳门美高梅手机网站 21

    输入站点中任一处理器上的arcgis
server地址,并输入站点管理员用户名、密码

    这里可以接纳是否通过web
adaptor管理站点,假使选取则可以通过http://webadaptorurl/mygis/manager来管理站点。否则,依然使用http://arcgisserverurl:6080/arcgis/manager来管理。

    因为大家要将web
adaptor代理后的地点表露给用户,来访问我们的地形图服务。我们并不愿意用户可以见见站点管理器界面,所以一旦没有特别要求,则默认不勾选。

    澳门美高梅手机网站 22

    点击配置,短暂的等候后,提醒配置成功!

     澳门美高梅手机网站 23

    这时我们可以在站点管理界面查看到成功安排的web adaptor

    澳门美高梅手机网站 24

  现在站点内发表的地形图服务,可以由此http://webadaptorurl/mygis/rest/services来查看访问了

  站点的负载能力是单个机器的N倍!N取决于参加集群的机器数量。

 

迄今截止,已做到ArcGIS
Server站点集群的建立及部署。

在继续小说中,将介绍ArcGIS Server的管理。

 

发表评论

电子邮件地址不会被公开。 必填项已用*标注