Java HotSpot持续时间极长的年轻集合

这是一个长时间运行的服务器应用程序，它会创建大量短期垃圾，并且在启动后几乎没有任何东西是永久的。大多数情况下，young gen收集速度很快，即使是10GB，也很快，因为它几乎都是垃圾，但我们偶尔会看到异常值。作为一个潜在的提示，我们正在一台CPU资源较多但内存较少12GB的机器上以较低的负载运行一个配置类似的服务器。我们在那里没有看到这种模式

java-Xms20g-Xmx20g-Xloggc:“./logs/gc.log”-XX:+printgDetails-XX:+printgDatestamps-XX:NewRatio=1-XX:+DisableExplicitGC-XX:+useSpining-XX:PreBlockSpin=1000-XX:-useCcounterdecage-XX:+UseTLAB-XX:+tieredcomployment-XX:reserveddecachesize=512m

下面是GC日志中的一个片段。因为sys时间也很高，所以可以安全地说它花费了全部的时间来实际执行GC工作（例如，而不是等待线程到达安全点）

2013-12-13T14:04:50.388+0000:56748.603[GC[PSYoungGen:10363808K->1248K（10421824K）]10569323K->20703K（20907584K），0.0035110秒][次：用户=0.03系统=0.00，实数=0.00秒]

2013-12-13T14:17:32.245+0000:57510.460[GC[PSYoungGen:10363808K->1600K（10435072K）]10569563K->207563K（20920832K），0.0038460秒][次：用户=0.04系统=0.00，实数=0.01秒]

2013-12-13T14:29:08.572+0000:58206.787[GC[PSYoungGen:10381824K->1408K（10430912K）]10587787K->207875K（20916672K），0.0045710秒][次：用户=0.04系统=0.00，真实=0.01秒]

2013-12-13T14:36:25.176+0000:58643.391[GC[PSYoungGen:10381632K->1600K（10442432K）]10588099K->208371K（20928192K），0.0040800秒][次：user=0.03 sys=0.00，real=0.00秒]

2013-12-13T14:44:04.409+0000:59102.624[GC[PSYoungGen:10397120K->1600K（10438848K）]10603891K->208715K（20924608K），14.7387710秒][次：用户=0.00sys=143.05，真实=14.74秒]

2013-12-13T14:52:50.287+0000:59628.502[GC[PSYoungGen:10397120K->11488K（10446720K）]10604235K->218819K（20932480K），0.0127280秒][次：用户=0.11系统=0.00，实数=0.01秒]

2013-12-13T14:59:34.934+0000:60033.149[GC[PSYoungGen:10418208K->1536K（10445760K）]10625539K->218931K（20931520K），211.1968100秒][次：user=0.00 sys=2067.08，real=211.16秒]

2013-12-13T15:12:04.478+0000:60782.693[GC[PSYoungGen:10408256K->15136K（10448064K）]10625651K->232723K（20933824K），0.0147670秒][次：用户=0.00系统=0.12，实数=0.01秒]

2013-12-13T15:23:02.123+0000:61440.338[GC[PSYoungGen:10426912K->12672K（10448768K）]10644499K->232635K（20934528K），0.0141040秒][次：用户=0.00系统=0.12，实数=0.02秒]

2013-12-13T15:31:09.119+0000:61927.334[GC[PSYoungGen:10424448K->5280K（10452160K）]10644411K->232907K（20937920K），0.8134440秒][次：user=1.22 sys=6.30，real=0.82秒]

2013-12-13T15:39:25.083+0000:62423.298[GC[PSYoungGen:10421024K->6208K（10449344K）]10648651K->235547K（20935104K），0.0087890秒][次：user=0.06 sys=0.00，real=0.01秒]

2013-12-13T15:47:52.781+0000:62930.996[GC[PSYoungGen:10421952K->7200K（10456960K）]10651291K->239123K（20942720K），0.0094460秒][次：用户=0.08系统=0.00，实数=0.01秒]

2013-12-13T15:58:18.594+0000:63556.809[GC[PSYoungGen:10433248K->6752K（10454848K）]10665171K->242331K（20940608K），0.0091570秒][次：用户=0.08系统=0.00，实数=0.01秒]

上述服务器上的规格为双4核X5570，内存为48 gb。HTOP显示使用了15GB，其余的缓存在任何时候都会使用略高于10GB的应用程序（终身使用很小）。这让我觉得这不是分页问题

---

我提到的另一台服务器是双8核E5-2690，具有32 gb的ram。这两个版本都在fedora上运行jre 1.7.0_25，尽管上面的服务器是一个非常旧的版本

如此高的

sys

时间是不寻常的。这是否会对您系统上的其他应用程序/活动造成干扰

---

我认为您还应该收集其他系统统计数据-

vmstat

，

netstat

，

iostat

，

mpstat

，以排除系统上活动的任何干扰或GC时间。将这些与YounGen相关联，以查看在这些长时间的YounGen暂停期间是否有任何尖峰

服务器专用于此应用程序，我认为不太可能。你说的是CPU争用还是别的什么？我从未见过这些盒子上有太多负载，我认为在GC期间从外部应用程序发生这种情况太巧合了…usr时间是0.00，所以它看起来像是在等待系统资源，而不是实际执行GC工作…您是否也可以尝试升级到jdk7u40并用任务控制监控GC？是的，可能需要几天时间。我忘了提一下，我们正在运行netsniff-ng，它绑定到一个收集所有网络流量的CPU（-b1）。该应用程序还从相同的套接字读取数据，并进行一些处理工作。它的平均速度可能在10 mb/s左右。也许应用程序的一个线程恰好位于netsniff CPU上，导致了这些长GC中的一个；等待线程到达安全点会显示为

sys

time吗？如果可能，可以尝试禁用netsniff ng。如果它阻塞了JVM，那么它应该在vmstats/mpstat中显示为上下文开关数量的增加/减少，等等。您也可以开始监视安全点，这有一个标志。。。但我不确定性能如何。那个的影响。。。因为它们太多了，可能会很重。