2

我最近遇到了性能问题，我在 tomcat 上运行的 Java webapp 会短时间挂起，导致流量积压，这可能使 webapp 在几分钟内不可用，我怀疑这与垃圾收集有关。

我是一个垃圾收集菜鸟，所以需要一些帮助。

我启用了并发标记清除垃圾收集器，希望这将消除暂停，但我还没有发现这是否已经解决了问题。

我还同时启用了详细的 GC 日志记录。

当前的java选项如下

-XX:MaxPermSize=128m -XX:+CMSClassUnloadingEnabled -XX:+UseConcMarkSweepGC -Xms4g -Xmx4g -Xss256k -verbose:gc -XX:+PrintGCDetails

通过检查 GC 输出，我注意到年轻代空间非常低，只有 243MB，并且很快就会耗尽，而在检查一段时间的输出时，我在 10 秒内计算了 23 个年轻代收集。

与此同时，总堆消耗量稳步上升，接近最大值，随后进行了完整的垃圾收集，将其从大约 3.5gb 降至 260mb，然后该模式再次自我重复。

完整 GC 的示例输出

[GC [ParNew: 232750K->12960K(249216K), 0.0160890 secs] 3836696K->3616934K(4166656K), 0.0162110 secs] [Times: user=0.12 sys=0.01, real=0.02 secs] 
[GC [ParNew: 234528K->11391K(249216K), 0.0127970 secs] 3838502K->3615402K(4166656K), 0.0129370 secs] [Times: user=0.12 sys=0.00, real=0.01 secs] 
[GC [ParNew: 232959K->10253K(249216K), 0.0097850 secs] 3836970K->3614841K(4166656K), 0.0098850 secs] [Times: user=0.11 sys=0.00, real=0.01 secs] 
[GC [1 CMS-initial-mark: 3604588K(3917440K)] 3615964K(4166656K), 0.0096810 secs] [Times: user=0.01 sys=0.00, real=0.01 secs] 
[CMS-concurrent-mark: 0.196/0.196 secs] [Times: user=1.44 sys=0.03, real=0.20 secs] 
[CMS-concurrent-preclean: 0.013/0.014 secs] [Times: user=0.04 sys=0.00, real=0.01 secs] 
[GC [ParNew: 231821K->6718K(249216K), 0.0090430 secs] 3836409K->3611789K(4166656K), 0.0091460 secs] [Times: user=0.08 sys=0.01, real=0.01 secs] 
[CMS-concurrent-abortable-preclean: 0.176/0.390 secs] [Times: user=0.97 sys=0.04, real=0.39 secs] 
[GC[YG occupancy: 124723 K (249216 K)][Rescan (parallel) , 0.0698120 secs][weak refs processing, 0.0038070 secs][class unloading, 0.0170180 secs][scrub symbol & string tables, 0.0098050 secs] [1 CMS-remark: 3605071K(3917440K)] 3729794K(4166656K), 0.1070920 secs] [Times: user=0.78 sys=0.02, real=0.11 secs] 
[GC [ParNew: 228286K->6428K(249216K), 0.0079910 secs] 3755282K->3534155K(4166656K), 0.0080720 secs] [Times: user=0.07 sys=0.00, real=0.01 secs] 
[GC [ParNew: 227996K->6880K(249216K), 0.0085010 secs] 3332282K->3111216K(4166656K), 0.0085990 secs] [Times: user=0.08 sys=0.00, real=0.01 secs] 
[GC [ParNew: 228448K->12440K(249216K), 0.0108230 secs] 2721177K->2505200K(4166656K), 0.0109290 secs] [Times: user=0.13 sys=0.00, real=0.01 secs] 
[GC [ParNew: 234008K->8251K(249216K), 0.0073110 secs] 2358432K->2132792K(4166656K), 0.0074120 secs] [Times: user=0.07 sys=0.00, real=0.00 secs] 
[GC [ParNew: 229819K->5170K(249216K), 0.0071920 secs] 2056138K->1831867K(4166656K), 0.0072880 secs] [Times: user=0.07 sys=0.01, real=0.01 secs] 
[GC [ParNew: 226738K->11119K(249216K), 0.0106230 secs] 1589903K->1374447K(4166656K), 0.0107180 secs] [Times: user=0.11 sys=0.00, real=0.01 secs] 
[GC [ParNew: 232687K->8624K(249216K), 0.0078450 secs] 1273082K->1049051K(4166656K), 0.0079440 secs] [Times: user=0.09 sys=0.00, real=0.01 secs] 
[GC [ParNew: 230192K->10130K(249216K), 0.0083440 secs] 733461K->513411K(4166656K), 0.0084420 secs] [Times: user=0.11 sys=0.00, real=0.01 secs] 
[GC [ParNew: 231698K->10655K(249216K), 0.0092440 secs] 544833K->323816K(4166656K), 0.0093450 secs] [Times: user=0.11 sys=0.00, real=0.01 secs] 
[CMS-concurrent-sweep: 4.481/4.569 secs] [Times: user=13.24 sys=0.49, real=4.57 secs] 
[CMS-concurrent-reset: 0.008/0.008 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] 
[GC [ParNew: 232223K->9791K(249216K), 0.0095050 secs] 495665K->273758K(4166656K), 0.0096020 secs] [Times: user=0.11 sys=0.00, real=0.01 secs] 
[GC [ParNew: 231359K->7434K(249216K), 0.0080890 secs] 495326K->271660K(4166656K), 0.0082230 secs] [Times: user=0.09 sys=0.00, real=0.01 secs] 
[GC [ParNew: 229002K->5732K(249216K), 0.0053690 secs] 493228K->269993K(4166656K), 0.0054630 secs] [Times: user=0.06 sys=0.00, real=0.01 secs] 
[GC [ParNew: 227300K->4017K(249216K), 0.0060080 secs] 491561K->268433K(4166656K), 0.0061010 secs] [Times: user=0.07 sys=0.00, real=0.00 secs]

我想了解这种模式是否正常，以及我可以做些什么来优化和改进 thisC.

我已经阅读了有关增加年轻代大小但对垃圾收集不太熟悉的信息，我不确定这是否是正确的方法。

4

1 回答 1

2

这看起来确实像您的年轻代大小太小 - 频繁的收集并不是真正的问题（这只是意味着您有一个内存密集型程序），但是您有很多内存被提升到下一代是有问题的. 一些东西：

  1. 您是否有任何可以池化的资源，例如您可以使用 ThreadPoolExecutor 而不是创建新的 Thread 对象，或者您可以池化您的数据库连接？这将减慢您的内存消耗 - 汇集的资源将保留在您的成熟空间中，您不必继续在年轻空间中重新分配它们。

  2. 如果这不是一个选项，或者如果这不会减少您的成熟空间消耗，那么增加您的年轻代大小。这样做的目的不是减少年轻代收集的数量（如果你将年轻代的大小加倍，那么你将减少一半的收集数量，但每个收集的成本可能会增加一倍**，所以你没有得到任何东西） ，而是这样做的目的是让您的年轻对象有更多时间超出范围，以免它们被提升到成熟空间。您想要进行的比较是完整收集的频率 - 如果在增加年轻代大小后您的完整收集较少，那么您已经成功，否则将您的年轻代大小减少回默认值。

** 这并不完全正确，因为年轻代收集器是一个复制收集器——它将活动对象复制到成熟空间，然后清除年轻空间。这意味着收集器运行的时间与活动对象的数量成正比，而不是与对象的总数成正比（就像标记扫描收集的情况一样）。理想情况下，通过增加年轻代的大小，您将减少活动对象的数量并加快收集时间以及减少成熟空间消耗。

于 2013-04-18T17:10:23.830 回答