根据本文，Linux 机器的 RAM 最好是索引大小的 1.5 倍。因此，为了验证这一点，我尝试在不同的 RAM 分配量中测试 solr 性能，并在两种情况下保持其他配置(即固态硬盘、8 核处理器、64 位)相同。
https://wiki.apache.org/solr/SolrPerformanceProblems
1) 最初，Linux 机器有 32 GB RAM，我为 solr 分配了 14GB。
导出CATALINA_OPTS="-Xms2048m -Xmx14336m -XX:+UseConcMarkSweepGC -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:./logs/info_error/tomcat_gcdetails.log"
1000个查询的平均搜索时间为300ms。
2) 之后，RAM 增加到 68 GB，其中我分配了 40GB 给 Solr。现在，奇怪的是，同一组查询的平均搜索时间为 3000 毫秒。
现在，在此之后，我在 68GB 机器上将 solr 分配的 RAM 减少到 25GB。但是，与第一种情况相比，搜索时间仍然更长。
我缺少什么。请推荐
最佳答案
在我看来，您使用的 Java 堆大小过高。
RAM 对于 Solr 来说非常重要，但主要是将索引文件保存在发生在 Java 堆空间之外的内存中。
Solr 默认情况下使用“MMapDirectory”，它将索引文件加载到操作系统磁盘缓存中，然后从那里映射到 Solr 进程的虚拟内存中。再次重要的是，这发生在 Java 堆空间之外。
您所说的文档中也提到了这一点:
A major driving factor for Solr performance is RAM. Solr requires sufficient memory for two separate things: One is the Java heap, the other is "free" memory for the OS disk cache.
...
For index updates, Solr relies on fast bulk reads and writes. For search, fast random reads are essential. The best way to satisfy these requirements is to ensure that a large disk cache is available.
要更好地理解这一点，请阅读 http://blog.thetaphi.de/2012/07/use-lucenes-mmapdirectory-on-64bit.html
那么Java堆空间应该有多大呢？我会从 2 GB 开始，然后查看 GC 日志
This is one of those questions that has no generic answer. You want a heap that's large enough so that you don't have OutOfMemory (OOM) errors and problems with constant garbage collection, but small enough that you're not wasting memory or running into huge garbage collection pauses. The long version: You'll have to experiment.
关于linux - solr 性能随 ram 大小的变化，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/29265693/