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工作，並為此感到自豪。 如果與超時相關的尷尬一直存在，我們會在數周的努力中為人們解決這類問題。

Answer 2

垃圾收集調整是一個復雜的主題。 您的垃圾收集暫停可能會或可能不會太長，具體取決於您的需求。 我們無法了解這些要求。 您的堆大小可能正確也可能不正確。 您的堆可能未正確分區。 您可能會受益於使用不同的垃圾收集算法。 我們無法為您回答這些問題。 垃圾收集沒有正確的公式。 因此，您所能做的就是開始修改它，直到您遇到滿足應用程序運行時行為特征的任何內容為止。

有很多關於如何管理JVM的選項。 你可以從這里開始。

Answer 3

GC峰值的條件是什么和不合理取決於給定的應用。

您需要在較長時間內觀察GC行為，以推斷某些峰值不合理地高於其他峰值。

在1-3秒內，FullGC暫停相對合理，堆大小為16-32GB。 YoungGC可以在200ms左右。

Answer 4

解決Solr垃圾收集問題的一種方法是移動許多大型數據結構，如filterCache和FieldCache堆外。

Heliosearch是一個Solr fork，它就是這樣做的（堆外數據結構）。 到目前為止，請參閱以下博客了解性能結果：

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

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