Java sparc T4 8核的G1 GC正确调谐_Java_Garbage Collection_Weblogic11g_Sparc_G1gc

Java sparc T4 8核的G1 GC正确调谐

java

Java sparc T4 8核的G1 GC正确调谐,java,garbage-collection,weblogic11g,sparc,g1gc,Java,Garbage Collection,Weblogic11g,Sparc,G1gc,我的应用程序部署在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

我的应用程序部署在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

设置STW工作线程的值。将n的值设置为逻辑处理器的数量。n的值与数字相同逻辑处理器的最大值为8

如果有八个以上的逻辑处理器，则设置n的值到大约5/8的逻辑处理器。这在大多数情况下都有效除较大的SPARC系统外的情况，其中n的值可以为大约5/16的逻辑处理器

关于什么是“逻辑处理器”，没有明确的说法。我搜索过web，它看起来可以理解为一个运行在物理处理器或内核中的线程。因此，运行此wl的机架中的“逻辑处理器”数量将达到128个（根据数据，2个8核处理器“能够在8个线程之间切换”）

但我听说这128个“逻辑处理器”中有64个是为数据库保留的，其余的是为运行Tuxedo和weblogic服务器而共享的。假设有两个WebLogic实例，并且安全地考虑TuxeDo和WL实例消耗相同数量的SUPDS，可以认为（64/3）*（5/16）~= 6或7并行GRTCHOST，因此1个或最多2个CUTCGTHOST是可接受的。您认为这些是开始调整的合理值吗？欢迎提出任何建议

编辑：到今天为止，我已经生成了一些启用了GCDetails的日志

我的解释是：

堆使用率随着用户执行任务而缓慢增长
永久堆使用率（蓝色之字形下的洋红线代表整个使用的堆）也是如此，尽管在永久堆中仍然有相当多的可用空间
恰恰相反，年轻一代的垃圾堆的边缘非常稀少，需要不断地进行垃圾收集
虽然这张图没有什么令人不安的地方，但趋势是向上的。此外：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名平行工人；由于congcthreads设置为4，我想我可以将ParallelGCThreads设置为16，或者将congcthreads减少为2。不确定哪种选择更好，可能是前者。但事实可能证明，这并不是那么重要

参考处理时间始终较高。著名的Beckwith文章提到：

如果您在参考处理过程中看到高时间，请打开通过在命令行-XX:+ParallelRefProcEnabled

这是我绝对认为我应该做的事情，我肯定会做的

然而，主要的问题是如何减少gc暂停的长度。更高的并行度可能会有所帮助，但问题可能与过于雄心勃勃的暂停时间有关；正如Oracle教程所说：

而不是使用平均响应时间（ART）作为指标来设置 XX：Max GcPaSuMiLIS=，考虑满足的设置值目标90%以上的时间。这意味着90%的用户提出请求不会经历比目标更高的响应时间。记得，暂停时间是一个目标，不能保证总是能够实现

因此，我认为这也有助于建立一个更现实的MaxgClis，比如600毫秒。如果这样一个目标能够实现，大多数用户都会非常高兴。如果暂停时间超过2秒，他们可能不会。您认为此参数是进一步优化的候选参数还是有其他建议

关于

键G1调谐标志是：

```
–XX:G1MixedCliveThresholdPercent
```
：要包括在混合集合中的旧区域中活动对象的占用阈值
```
–XX:G1HeapWastePercent
```
：堆中可容忍的垃圾阈值
```
–XX:G1MixedAccountTarget
```
：应在其中收集最多G1MixedCliveThresholdPercent live数据的区域的混合垃圾收集的目标数量
```
–XX:G1oldcSetRegionResholdPercent
```
：混合收集期间可收集的最大旧区域数限制

您的命令行选项还应包含GC日志记录：

-XX:+PrintGCDetails-XX:+PrintGCTimeStamps

考虑到

-XX:ParallelGCThreads

，您可以尝试使用例如一半或全部“处理器”-64个，然后从那里开始。此外，您需要考虑您的POOLSIZE＝100，所以在需要保持池繁忙的情况下，需要设置RealGcTyx＝28或更少。考虑到G1调优选项，请参阅以下参考资料：

Javaone 2013G1调优，以及Javaone 2012会话：G1垃圾收集器性能调优[]，[]-在本讲座的最后一部分，他们介绍了一些G1场景和可能应用的调优选项

请参见G1命令行选项和