我们已经运行了3节点DSE SOLR集群，并且最近添加了一个新核心。经过大约一周的运行，所有的SOLR节点现在都是OOMing。填满JVM堆（设置为8GB）和系统内存。然后还不断地将memtables刷新到磁盘上。
群集是DSE 3.2.5，RF = 3
这是来自新核心的solrconfig：
答案 0 :(得分：0)
您的Solr索引相对于OS可用于缓存文件系统页面的系统内存量有多大。基本上，您的Solr索引需要适合OS文件系统缓存（DSE启动后可用的系统内存量，但尚未处理任何大量数据。）
此外，每个节点上还填充了多少个Solr文档（Cassandra行）和多少个字段（Cassandra列）？没有硬性限制，但是每个节点有400到1亿是一个很好的指导作为上限。
并且，如果重新启动DSE，但在开始在服务器上加载之前，系统内存和可用的JVM堆数量是多少？
答案 1 :(得分：0)
对于RF = N，其中N是群集中或至少搜索数据中心中的节点总数，所有数据都将存储在所有节点上，这对于较小的数据集是可以的，但对于较大的数据集则不合适数据集。
对于RF = n，这意味着每个节点将具有X / N * n行或文档，其中X是数据中心中所有列族的行或文档的总数。 X / N * n是您应该尝试保持在1亿以下的数字。这不是一个硬限制 - 一些数据集和硬件可能能够处理更多，而一些数据集和硬件可能甚至不能保持那么多。您必须发现最适合您自己的应用程序的数字，但4000万到1亿的范围是一个良好的开端。
简而言之，对于Solr节点，最安全的估计是X / N * n保持在4000万以下。对于某些数据集和更强大的硬件，100可能没问题。
答案 2 :(得分：0)
就调优而言，使用大量堆的一个常见原因是大量使用Solr facets和过滤查询。
一种技术是使用“DocValues”字段作为构面，因为DocValues可以存储在堆外。
过滤查询可以标记为cache = false以节省堆内存。
此外，各种Solr缓存可以减小尺寸甚至设置为零。那是在solrconfig.xml中。