适合sparc G1 8核的T4 GC调优

Question

我的应用程序部署在运行在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。 如果有8个以上的逻辑处理器，则将n的值设置为逻辑处理器的大约5/8。除了较大的SPARC系统外，在大多数情况下，n的值可以约为逻辑处理器的5/16。

没有明确说明什么是“逻辑处理器”。我搜索过网络，看起来它可以理解为运行在物理处理器或内核中的线程。根据http://www.oracle.com/technetwork/server-storage/sun-sparc-enterprise/documentation/o11-090-sparc-t4-arch-496245.pdf的说法，在这个wl正在运行的机架上，“逻辑处理器”的数量将达到128个(根据http://www.oracle.com/technetwork/server-storage/sun-sparc-enterprise/documentation/o11-090-sparc-t4-arch-496245.pdf的说法，8个核心处理器“具有在8个线程之间切换的能力”)。

但我被告知，在这128个“逻辑处理器”中，有64个是为数据库保留的，其余的用于运行Tuxedo和weblogic服务器。假设有两个weblogic实例，并且可以安全地考虑tuxedo和wl实例消耗相同数量的三个，则可以认为(64/3)*(5/16) ~= 6或7 ParallelGCThreads，因此可以接受1或最多2 ConcGCThreads。

您认为这些值是启动调优的合理值吗？任何建议都是欢迎的。

编辑:到今天为止，我已经用GCDetails Edit生成了一些日志。下面是gc查看器中的外观

​

​

我的解释是：

• 随着用户执行他们的任务，堆的使用慢慢增长。
• 终身堆的使用(蓝色字形下的洋红线代表整个使用过的堆)也是这样，尽管在终身使用的世代中仍然有相当大的空间可用。
• 相反，年轻一代堆的边缘相当稀少，需要稳定地收集垃圾。
• 虽然这幅画并没有立即引起什么不安，但趋势是向上的。此外: gc暂停时间(如果不涉及初始标记，则略超过1s，否则几乎是2s )远远超过300 1s的目标目标。

只显示垃圾收集日志：

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设置为2，也可以将ConcGCThreads降为2。不知道哪种选择更好，也许前者更好。但事实可能证明，这一点并不重要。

参考处理时间一直很高。著名的贝克威文章提到：

如果您在引用处理过程中看到很高的时间，那么请在命令行-XX:+ParallelRefProcEnabled上启用以下选项，从而打开并行引用处理。

这是我绝对认为我应该做的事，而且我肯定会这样做。

但是，主要的问题是如何减少gc暂停的长度。更高的ParallelGCThreads可能会有所帮助，但这个问题可能与过于雄心勃勃的暂停时间有关；正如甲骨文教程所指出的：

与其使用平均响应时间(ART)作为标准来设置XX:MaxGCPauseMillis=，不如考虑设置能够在90%或更多时间内达到目标的值。这意味着90%的请求用户不会体验到高于目标的响应时间。请记住，暂停时间是一个目标，不能保证总是得到满足。

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

问候

Answer 1

键G1调优标志是：

• –XX:G1MixedGCLiveThresholdPercent：将包含在混合集合中的旧区域中的活动对象的占用率阈值。
• –XX:G1HeapWastePercent：堆中可以容忍的垃圾阈值。
• –XX:G1MixedGCCountTarget：应该收集最多G1MixedGCLiveThresholdPercent活动数据的区域的混合垃圾收集的目标数量。
• –XX:G1OldCSetRegionThresholdPercent：对混合集合期间可以收集的最大旧区域数的限制。

命令行选项还应该包含GC日志记录：–XX:+PrintGCDetails –XX:+PrintGCTimeStamps。

考虑到-XX:ParallelGCThreads，您可以尝试例如一半或全部“处理器”- 64在您的情况下，并从那里开始。此外，您还需要考虑您的PoolSize=100，因此可能需要设置ParallelGCThreads=28或更少，以防您需要保持池的忙碌。

考虑到G1优化选项，请参见以下资源

• Javaone 2013 G1 Tuning [谈话]和JavaOne 2012 session：G1垃圾收集器性能优化 [YouTube]，[PDF格式] --在演讲的最后一部分，它们介绍了一些G1场景和可能应用的调优选项。
• G1:一个垃圾收集器来管理它们
• 请参阅G1命令行选项和开始使用G1垃圾收集器中的最佳实践。