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。

如果逻辑处理器超过八个，则设置n的值   到大约5/8的逻辑处理器。这大多数都适用   除了较大的SPARC系统，其中n的值可以是   大约5/16的逻辑处理器。

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

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

您认为这些是开始调整的合理值吗？欢迎提出任何建议。

编辑：截至今天，我已经启用了GCDetails生成的一些日志。这是它在gc viewer中的样子

g1 garbage collection logging

我的解释：

当用户执行任务时，堆使用量会慢慢增长
终身堆的使用（蓝色曲折下的洋红色线代表整体使用的堆）也有，尽管在终身代中仍有相当数量的空间可供使用
恰恰相反，年轻一代的利润很少，而且需要稳步收集垃圾。
虽然没有什么能让这张照片立即令人不安，但趋势是向上的。此外：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文章提到：

如果您在参考处理过程中看到很多次，请打开并行引用处理通过启用以下选项命令行-XX：+ ParallelRefProcEnabled。

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

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

而不是使用平均响应时间（ART）作为度量来设置 XX：MaxGCPauseMillis =，考虑设置符合的值目标90％的时间或更多。这意味着90％的用户提出请求不会经历高于目标的响应时间。记得，暂停时间是一个目标，并不能保证永远满足。

所以我认为它也可以帮助建立一个更真实的MaxGCPauseMillis，比如600ms。如果要实现这样的目标，大多数用户都会非常高兴。如果暂停时间超过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调整 [talk]和JavaOne 2012会话： G1垃圾收集器性能调整 [youtube]，[{{3}在谈话的最后部分，他们提出了一些G1场景和应用的可能的调整选项。
PDF
请参阅G1: One Garbage Collector To Rule Them All。

G1命令行选项和最佳做法

适用于sparc T4 8核的G1 GC调整

1 个答案: