JVM 設定
最佳化 JVM 可能是充分利用您的 Solr 安裝的關鍵因素。
設定您的 JVM 是一個複雜的主題，完整的討論超出本文檔的範圍。幸運的是，大多數現代 JVM 在使用預設設定時，都能很好地利用可用資源。以下各節包含一些在預設設定對您的情況不理想時可能有所幫助的提示。
如需有關改善 Solr 效能的更多一般資訊，請參閱 Solr Wiki 中的Solr 效能因素。
選擇記憶體堆積設定
最重要的 JVM 設定控制分配給 JVM 的堆積：-Xms，它設定 JVM 記憶體堆積的初始大小；以及 -Xmx，它設定堆積的最大大小。將這兩個選項設定為相同的值是一種常見的做法。
堆積大小至關重要，但不幸的是，沒有「一體適用」的解決方案，您必須使用您的資料和應用程式進行測試。確定正確大小的最佳方法是分析位於您記錄目錄中的垃圾收集 (GC) 記錄。有各種工具可協助分析這些記錄，特別是顯示 GC 完成後使用的記憶體量（GCViewer 和 GCEasy 是兩個）。您也可以在 Solr 執行時附加 jconsole（隨大多數 Java 執行階段分發）以檢查記憶體消耗。這將顯示所需的絕對最小記憶體量；增加 25-50% 的「餘裕」是一個合理的起點。
有幾個重點需要記住
-
以過少的「餘裕」分配給堆積執行 Solr，可能會導致持續的 GC 消耗過多資源。因此有上述 25-50% 的建議。
-
Solr 廣泛使用 MMapDirectory，它使用 未 為 JVM 保留的 RAM 來儲存大多數 Lucene 索引。因此，應盡可能為作業系統保留更多記憶體以用於此目的。
-
在維持良好效能的同時，分配的堆積應盡可能小。8-16Gb 非常常見，有時會使用更大的堆積。當堆積成長到較大的大小時，務必在投入生產環境之前進行廣泛測試。
-
當使用支援 G1GC 的 JVM 時（Java 9 和更新版本），目前首選 G1GC 垃圾收集器。
-
現代硬體可以配置數百 GB 的實體 RAM 和許多 CPU。在這些情況下，通常最好執行多個 JVM，每個 JVM 的堆積中分配有限的記憶體量。實現此目的的一種方法是以 Docker 容器 執行 Solr。
-
最好定期重新分析 GC 記錄和/或使用指標報告進行監控，以查看記憶體使用量是否因應用程式、文件數量等變更而變更。
-
Solr 將使用一個選項執行，該選項會導致 JVM 在 OutOfMemoryError 例外狀況時當機。當系統資源耗盡時，這會強制停止 Solr，而不是在不確定的狀態下繼續。您還可以透過
solr.in.sh中的值要求在 OOME 時進行堆積傾印。 -
所有目前的 (Java 11) 垃圾收集器都可能觸發「停止世界」收集，這會暫停 JVM 直到完成。如果透過監控發現這些垃圾收集很頻繁且超過應用程式可容忍的範圍，則應考慮進行額外的調整。「停止世界」的暫停時間超過 5 秒的情況很少能接受，理想情況下應低於 1 秒。
請查閱您的 JVM 供應商的文件以了解您特定案例的詳細資訊，上述建議僅作為起點。
