我的应用程序部署在 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的说法，该 wl 运行的机架中的“逻辑处理器”数量因此将达到 128 个（2 个 8 核处理器“能够在 8 个线程之间切换” /server-storage/sun-sparc-enterprise/documentation/o11-090-sparc-t4-arch-496245.pdf）。
但有人告诉我，这 128 个“逻辑处理器”中有 64 个是为数据库保留的，其余的被共享用于运行 Tuxedo 和 weblogic 服务器。假设有两个 weblogic 实例，并且认为 tuxedo 和 wl 实例消耗相同数量的线程是安全的，可以认为 (64/3)*(5/16) ~= 6 或 7 ParallelGCThreads 和因此 1 个或最多 2 个 ConcGCThreads 是可以接受的。
您认为这些是开始调整的合理值吗？欢迎任何建议。
编辑：截至今天，我已经生成了一些启用 GCDetails 的日志。这是它在 gc 查看器中的外观
我的解释：
- 随着用户执行任务，堆使用量缓慢增长
- 终身堆使用（蓝色锯齿形下方的洋红色线代表整体已用堆）也可以，尽管在终身代中仍有相当多的可用空间
- 恰恰相反，年轻代堆的边缘非常稀缺，需要稳定地进行垃圾收集
- 尽管这张照片没有立即令人不安的地方，但趋势是向上的。此外：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个并行worker；由于 ConcGCThreads 设置为 4，我想我可以设置 ParallelGCThreads=16 或将 ConcGCThreads 减少到 2。不确定哪个选项更好，可能是前者。但它可能毕竟不是那么重要。
参考处理时间一直很长。著名的 Beckwith 文章提到：
如果您在参考处理期间看到高时间，请通过启用命令行上的以下选项 -XX:+ParallelRefProcEnabled 来打开并行参考处理。
这是我绝对认为我应该做而且肯定会做的事情。
然而，主要问题是如何减少 gc 暂停的长度。更高的 ParallelGCThreads 可能会有所帮助，但也许这个问题与过于雄心勃勃的暂停时间有关；正如 Oracle 教程所说：
不要使用平均响应时间 (ART) 作为设置 XX:MaxGCPauseMillis= 的指标，而是考虑设置将在 90% 或更多时间满足目标的值。这意味着 90% 的发出请求的用户不会遇到高于目标的响应时间。请记住，暂停时间是一个目标，不能保证总是能达到。
所以我认为它也可以帮助设置一个更现实的 MaxGCPauseMillis，比如 600 毫秒。如果实现了这样的目标，大多数用户都会非常高兴。如果暂停时间超过 2 秒，他们可能不会。您认为该参数是否适合进一步调整或有其他建议？
问候