我的应用程序部署在Solaris上运行的weblogic上,采用双SPARC T4 8核3.0 GHz.这个weblogic实例正在使用g1 gc,我认为可以改进当前的配置:
GC_OPTIONS=" -server -XX:ConcGCThreads=4 -XX:+UseG1GC -XX:+DisableExplicitGC
-XX:MaxGCPauseMillis=300 -XX:GCPauseIntervalMillis=1000 -XX:+UseNUMA
-XX:+UseCompressedOops -XX:ReservedCodeCacheSize=128m
-Dweblogic.ThreadPoolPercentSocketReader=50 -Dweblogic.ThreadPoolSize=100
-Dweblogic.SelfTunningThreadPoolSizeMin=100 "
令我感到震惊的是,ConcGCThreads已经设置好,而没有为ParallelGCThreads建立一个值.我认为这将使这两个值显示出合理的比例是一个良好的开端.甲骨文的文档说:
-XX:ParallelGCThreads=n
Sets the value of the STW worker threads. Sets the value of n to the
number of logical processors. The value of n is the same as the number
of logical processors up to a value of 8.
If there are more than eight logical processors, sets the value of n
to approximately 5/8 of the logical processors. This works in most
cases except for larger SPARC systems where the value of n can be
approximately 5/16 of the logical processors.
但我被告知这128个“逻辑处理器”中有64个是为数据库保留的,其余的是为运行Tuxedo和weblogic服务器而共享的.假设有两个weblogic实例,并且认为tuxedo和wl实例消耗相同数量的threds是安全的,可以认为(64/3)*(5/16)〜= 6或7个ParallelGCThreads和因此,1个或最多2个ConcGCThreads是可以接受的.
你认为这些是开始调整的合理值吗?任何建议都是受欢迎的.
编辑:截至今天,我已经启用了GCDetails生成的一些日志.这是它在gc viewer中的外观
我的解释:
>当用户执行任务时,堆使用量会慢慢增长
>终身堆使用(蓝色曲折下的洋红色线代表整体使用的堆)也有,尽管在终身代中仍有相当数量的可用空间
>恰恰相反,年轻一代的边缘很稀缺,需要稳步收集垃圾
>虽然没有什么能让这张照片立即令人不安,但趋势是向上的.此外:gc暂停时间(如果不涉及初始标记,略大于1s,否则几乎为2s)远远超过300ms的目标目标
只是显示垃圾收集日志:
2014-01-16T11:18:12.728+0100: 50293.457: [GC pause (young), 1.36713100 secs]
[Parallel Time: 1308.6 ms]
[GC Worker Start (ms): 50293458.0 50293458.0 50293458.0 50293458.1 50293458.1 50293458.1 50293458.2 50293458.2
Avg: 50293458.1, Min: 50293458.0, Max: 50293458.2, Diff: 0.2]
[Ext Root Scanning (ms): 982.5 174.5 146.2 150.6 170.6 139.6 154.5 158.8
Avg: 259.7, Min: 139.6, Max: 982.5, Diff: 842.9]
[Update RS (ms): 0.0 16.9 36.2 42.3 18.6 54.6 38.8 34.9
Avg: 30.3, Min: 0.0, Max: 54.6, Diff: 54.6]
[Processed Buffers : 0 15 21 31 18 27 11 21
Sum: 144, Avg: 18, Min: 0, Max: 31, Diff: 31]
[Scan RS (ms): 0.2 9.8 9.7 8.7 10.0 10.0 8.1 9.0
Avg: 8.2, Min: 0.2, Max: 10.0, Diff: 9.8]
[Object Copy (ms): 275.1 132.6 142.2 131.8 133.9 129.4 131.9 130.5
Avg: 150.9, Min: 129.4, Max: 275.1, Diff: 145.6]
[Termination (ms): 0.0 924.0 923.4 924.2 924.5 924.0 924.3 924.5
Avg: 808.6, Min: 0.0, Max: 924.5, Diff: 924.5]
[Termination Attempts : 1 1049 1140 1011 881 979 894 780
Sum: 6735, Avg: 841, Min: 1, Max: 1140, Diff: 1139]
[GC Worker End (ms): 50294715.8 50294715.9 50294716.0 50294715.9 50294715.9 50294715.9 50294715.9 50294715.9
Avg: 50294715.9, Min: 50294715.8, Max: 50294716.0, Diff: 0.1]
[GC Worker (ms): 1257.9 1257.9 1257.9 1257.9 1257.7 1257.8 1257.7 1257.7
Avg: 1257.8, Min: 1257.7, Max: 1257.9, Diff: 0.3]
[GC Worker Other (ms): 50.8 50.8 50.7 50.8 50.9 50.9 50.9 50.9
Avg: 50.8, Min: 50.7, Max: 50.9, Diff: 0.2]
[Clear CT: 1.1 ms]
[Other: 57.4 ms]
[Choose CSet: 0.1 ms]
[Ref Proc: 49.8 ms]
[Ref Enq: 0.1 ms]
[Free CSet: 5.9 ms]
[Eden: 1322M(1322M)->0B(1312M) Survivors: 68M->78M Heap: 4494M(6952M)->3182M(6952M)]
[Times: user=9.12 sys=0.18, real=1.37 secs]
到目前为止,没有疏散失败,大量的物体分配或完整的垃圾收集事件.有一点,如果服务器被阻止,除了诱导一个完整的gc之外别无选择.
有8名并行工人;由于ConcGCThreads设置为4,我想我可以设置ParallelGCThreads = 16或将ConcGCThreads减少到2.不确定哪个选项更好,可能前者是.但毕竟它可能不那么重要.
参考处理时间一直很高.着名的Beckwith文章提到:
If you see high times during reference processing then please turn on
parallel reference processing by enabling the following option on the
command line -XX:+ParallelRefProcEnabled.
这是我绝对认为我应该做的事情,肯定会.
然而,主要问题是如何减少gc暂停的长度.更高的ParallelGCThreads可能有所帮助,但也许这个问题与过于雄心勃勃的暂停时间有关;正如Oracle教程所说:
Instead of using average response time (ART) as a metric to set the
XX:MaxGCPauseMillis=, consider setting value that will meet the
goal 90% of the time or more. This means 90% of users making a request
will not experience a response time higher than the goal. Remember,
the pause time is a goal and is not guaranteed to always be met.
所以我认为它也可以帮助建立一个更真实的MaxGCPauseMillis,比如600ms.如果要实现这样的目标,大多数用户都会非常高兴.如果暂停时间超过2秒,他们可能不会.您认为此参数是进一步调整的候选者还是有任何其他建议?
问候