我的应用程序部署在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秒,他们可能不会.您认为此参数是进一步调整的候选者还是有任何其他建议？

问候