JVM 设置
优化 JVM 可以是充分利用 Solr 安装的关键因素。
配置 JVM 是一个复杂的主题，完整的讨论超出了本文档的范围。幸运的是，大多数现代 JVM 在使用默认设置时都非常擅长充分利用可用资源。以下部分包含一些在默认设置不适合您的情况下可能有用的提示。
有关提高 Solr 性能的更多一般信息，请参阅 Solr Wiki 中的 Solr 性能因素。
选择内存堆设置
最重要的 JVM 配置设置控制分配给 JVM 的堆：-Xms，它设置 JVM 内存堆的初始大小，以及 -Xmx，它设置堆的最大大小。将这两个选项设置为相同的值是一种常见的做法。
堆大小至关重要，不幸的是没有“一刀切”的解决方案，您必须使用您的数据和应用程序进行测试。确定正确大小的最佳方法是分析位于您的 logs 目录中的垃圾收集 (GC) 日志。有各种工具可以帮助分析这些日志，特别是显示 GC 完成后使用的内存量（GCViewer 和 GCEasy 是其中两个）。您还可以附加 jconsole（与大多数 Java 运行时一起分发）以检查 Solr 运行时内存消耗。这将显示所需的绝对最小内存量；添加 25-50% 的“余量”是一个合理的起点。
有几点需要记住
-
使用为堆分配的太少“余量”运行 Solr 会导致持续的 GC 消耗过多的资源。因此，上面的 25-50% 建议。
-
Solr 广泛使用 MMapDirectory，它使用 未为 JVM 保留的 RAM 来存储大部分 Lucene 索引。因此，应尽可能多地为操作系统保留内存以用于此目的。
-
在保持良好性能的同时，分配的堆应尽可能小。8-16Gb 很常见，有时会使用更大的堆。当堆增长到更大的大小时，必须在投入生产之前进行广泛的测试。
-
当使用支持 G1GC 垃圾回收器的 JVM（Java 9 及更高版本）时，目前首选 G1GC 垃圾回收器。
-
现代硬件可以配置数百 GB 的物理 RAM 和许多 CPU。在这些情况下，通常最好运行多个 JVM，每个 JVM 分配有限的堆内存。实现此目的的一种方法是将 Solr 作为 Docker 容器运行。
-
定期重新分析 GC 日志和/或使用 指标报告进行监控，以查看内存使用情况是否因应用程序、文档数量等变化而发生变化，这是一个很好的做法。
-
Solr 将使用一个选项运行，该选项会导致 JVM 在发生 OutOfMemoryError 异常时崩溃。当系统资源耗尽时，这将强制停止 Solr，而不是在不确定的状态下继续运行。您还可以通过
solr.in.sh中的值请求在发生 OOME 时生成堆转储。 -
当前所有（Java 11）垃圾回收器都可能出现 “stop the world” 集合，这将暂停 JVM 直到完成。如果通过监控发现这些垃圾回收过于频繁，且超出您的应用程序可容忍的范围，则应考虑进行额外的调整。“stop the world” 暂停超过 5 秒的情况很少能被接受，理想情况下应该小于 1 秒。
请查阅您的 JVM 供应商的文档，了解您特定情况下的具体信息，以上建议仅作为起点。
