Adob​​e Experience Manager（AEM），Java垃圾回收调整和内存管理

Question

我目前正在为客户端站点（Java语言）使用Adobe Experience Manager。它采用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，然后压移+ 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

老少面积比是interms 1：3，但它可能变化取决于在 短暂的对象和长寿对象的应用程序使用。如果短命的对象多于那么年轻的空间可以延长，例如2：3（年轻的：旧的）。比例增加的原因是 ，以避免scavange垃圾循环。当分配更多的短命对象时，年轻的空间填充得很快并导致清除GC循环内因会影响应用程序的性能。当比值 增加时，则当前值有可能减少清除GC循环。 当年轻的空间增加自动幸存者和伊甸园空间相应增加。 CMS策略用于减少应用程序的暂停时间，针对较大内存的G1策略 具有高吞吐量。 Gc政策可以根据应用程序的需要进行更改。

为G1推荐使用案例：

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