Adobe Experience Manager (AEM)、Java 垃圾收集调优和内存管理

Question

我目前正在将 Adob​​e Experience Manager 用于客户的网站（Java 语言）。它使用 openJDK：

#java -version

java version "1.7.0_65"
OpenJDK Runtime Environment (rhel-2.5.1.2.el6_5-x86_64 u65-b17)
OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)

它在 Rackspace 上运行，具有以下特性：

vCPU: 4
Memory: 16GB
Guest OS: Red Hat Enterprise Linux 6 (64-bit)

自从它投入生产以来，我一直在体验应用程序的性能非常缓慢。就像这样我启动应用程序，一切都很顺利，然后 3 到 4 天后 CPU 使用率飙升至 400%（约 4000 个用户/天访问该站点）。我遇到了一些 OOM 异常（1 或 2），但大多数情况下该站点异常缓慢，并且从未成为 OOM 异常。由于我是 Java 内存管理的新手，我开始阅读它的工作原理并找到了 jstat 之类的工具。当系统第二次不堪重负时，我跑了：

#top

得到java进程的PID，然后按shift+H，注意CPU百分比高的线程的PID。然后我跑了

#sudo -uaem jstat <PID>

得到一个线程转储并转换了我之前写下的线程 PID，并在转储中搜索它们的十六进制值。毕竟，我终于发现垃圾收集器由于某种原因而翻转并不奇怪。

我开始阅读大量有关 Java GC 调优的内容，并提出了以下 Java 选项。 因此使用以下选项重新启动应用程序：

java

-Dcom.day.crx.persistence.tar.IndexMergeDelay=0 
-Djackrabbit.maxQueuedEvents=1000000 
-Djava.io.tmpdir=/srv/aem/tmp/

-XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/srv/aem/tmp/ 
-Xms8192m -Xmx8192m 
-XX:PermSize=256m 
-XX:MaxPermSize=1024m 
-XX:+UseParallelGC 
-XX:+UseParallelOldGC 
-XX:ParallelGCThreads=4 
-XX:NewRatio=1

-Djava.awt.headless=true 
-server 
-Dsling.run.modes=publish 
-jar crx-quickstart/app/cq-quickstart-6.0.0-standalone.jar start 
-c crx-quickstart -i launchpad -p 4503 
-Dsling.properties=conf/sling.properties

看起来它的性能要好得多，但我认为它可能需要更多的 GC 调整。

当我跑步时：

#sudo -uaem jstat <PID> -gcutils

我明白了：

S0     S1     E      O       P      YGC   YGCT     FGC  FGCT      GCT   
0.00   0.00   55.97  100.00  45.09  4725  521.233  505  4179.584  4700.817

4 天后我重新启动它。

当我跑步时：

#sudo -uaem jstat <PID> -gccapacity

我明白了：

NGCMN       NGCMX       NGC         S0C         S1C         EC                  
4194304.0   4194304.0   4194304.0   272896.0    279040.0    3636224.0   

OGCMN   OGCMX       OGC         OC          PGCMN       PGCMX  
4194304.0   4194304.0   4194304.0   4194304.0   262144.0    1048576.0

PGC         PC          YGC     FGC
262144.0    262144.0    4725    509

4 天后我重新启动它。

这些结果比我开始时要好得多，但我认为它可以变得更好。我不太确定下一步该做什么，因为我不是 GC 专业人士，所以我想知道你们是否对我有任何关于如何获得更好的应用程序/GC 性能的提示或建议，以及是否有任何明显的事情，比如比率和youngGen 和 oldGen 的大小？

我应该如何设置幸存者和伊甸园的大小/比率？ 我应该像使用 CMS GC 还是 G1 一样更改 GC 类型？ 我应该怎么做？

任何建议都会有所帮助。

最好的，

尼古拉

Answer 1

年轻人和老年人的面积比例是 1:3，但它可能会有所不同，具体取决于应用程序的使用情况 寿命短的物体和寿命长的物体。如果寿命短的物体更多，那么 可以扩展年轻空间，例如 2:3 (young:old)。增加比率的原因是 避免清除垃圾循环。当分配更多的短期对象时，年轻空间 快速填充并导致清除 GC 循环进而影响应用程序性能。当比率 再增加当前值，则有可能减少清除 GC 周期。 当年轻空间自动增加时，survivor 和 Eden 空间也相应增加。 用于减少应用程序暂停时间的 CMS 策略和针对更大内存的 G1 策略 具有高吞吐量。可以根据应用程序的需要更改 Gc 策略。

G1 推荐用例：

G1 的第一个重点是为运行需要大堆且 GC 延迟有限的应用程序的用户提供解决方案。 这意味着大约 6GB 或更大的堆大小，以及低于 0.5 秒的稳定且可预测的暂停时间。 当您使用 8G 堆大小时，您可以针对相同环境使用 G1 gc 策略进行测试，以检查 GC 性能。