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

Question

当solr中的主服务器和从服务器之间存在复制时(tomcat是容器),存在GC峰值(大约需要200ms)并且它似乎回收了比必要资源(内存)更多的资源(内存大大减少)量).首先,这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工作,并为此感到自豪.如果与超时相关的尴尬一直存在,我们会在数周的努力中为人们解决这类问题.