java - Java/Tomcat/Solr 中的垃圾收集优化

Question

当 solr(tomcat 是容器)中的主从之间存在复制时，会出现 GC 尖峰(大约需要 200 毫秒)并且它似乎回收了比必要的更多的资源(内存)(大幅下降使用的内存量)。首先，这个200ms合理吗？其他人看到的东西？其次，有没有一种方法可以让 GC 不那么激烈(回收更少，从而减少中断)，但我不确定我正在尝试做的事情是否可行，或者我是否在朝着正确的方向解决问题。

这是我的 GC 参数供您引用:

-XX:+DisableExplicitGC 
-XX:+UseConcMarkSweepGC 
-XX:+CMSParallelRemarkEnabled
-XX:CMSInitiatingOccupancyFraction=30
-XX:ParallelCMSThreads=6 
-XX:PermSize=64m 
-XX:MaxPermSize=64m 
-Xms32g 
-Xmx32g 
-XX:NewSize=512m
-XX:MaxNewSize=512m
-XX:TargetSurvivorRatio=90 
-XX:SurvivorRatio=8 
-XX:MaxTenuringThreshold=15 
-XX:+UseStringCache 
-XX:+OptimizeStringConcat 
-XX:+UseCompressedOops 
-XX:+PrintGC 
-XX:+PrintGCDetails 
-XX:+PrintGCTimeStamps
-XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=...
-XX:+UseNUMA 
-XX:+UseCompressedStrings 
-XX:+UseBiasedLocking

Answer 1

实际上有一种快速而简单的方法可以解决这些与 GC 相关的超时问题，它不依赖于复杂的数据收集和调整，而且只要您在 Linux 上运行，它就每次都有效。

如其他地方所述，由 Newgen、CMS 或 FullGC 暂停引起的超时峰值是否可以接受取决于您的要求。此外，调整 HotSpot GC 机制确实是一门复杂的艺术，您通常需要更多的细节和迭代实验来弄清楚如何改进当前的行为。

但是，如果您希望在没有获得 GC 调优博士学位的情况下消除所有这些暂停和相关超时，有一个简单的灌篮方法:Zing JVM 将运行 32GB 堆 Solr 设置，GC 永远不会费力，并且没有任何与 GC 相关的暂停、中断或相关超时。它开箱即用，使用默认参数，几乎不需要调整。

是的，我在 Azul 工作，并为此感到自豪。我们为遇到此类问题的人们节省了数周的时间，如果超时相关的尴尬一直都在发生。