4

当 solr 中的 master 和 slave 之间存在复制时（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
4

4 回答 4

5

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

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

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

是的，我在 Azul 工作，并为此感到自豪。如果与超时相关的尴尬一直存在，我们会为遇到此类问题的人节省数周的努力和大量的时间。

于 2013-09-19T14:25:30.297 回答
3

垃圾收集调优是一个复杂的话题。您的垃圾收集暂停可能会也可能不会太长，具体取决于您的需要。我们无法知道这些要求。您的堆大小可能正确也可能不正确。您的堆可能未正确分区。您可能会受益于使用不同的垃圾收集算法。我们无法为您回答这些问题。垃圾回收没有正确的公式。因此，您所能做的就是开始修改它，直到满足满足您的应用程序运行时行为特征的任何条件。

如何管理 JVM 有很多选择。你可以从这里开始。

于 2013-09-18T19:42:38.063 回答
1

解决 Solr 垃圾收集问题的一种方法是将许多大型数据结构（如 filterCache 和 FieldCache 堆外）移动。

Heliosearch 是一个 Solr 分支，它就是这样做的（堆外数据结构）。到目前为止，请参阅以下博客以了解性能结果：

http://heliosearch.org/off-heap-filters/

http://heliosearch.org/solr-off-heap-fieldcache/

于 2014-03-05T14:51:53.677 回答
1

就 GC 峰值而言，什么是合理的，什么是不合理的取决于给定的应用程序。

您需要在较长时间内观察 GC 行为，以推断某些尖峰不合理地高于其他尖峰。

在 16-32GB 堆大小的情况下，1-3 秒的 FullGC 暂停是相对合理的。YoungGC 可以在 200ms 左右。

于 2013-09-18T22:16:21.443 回答