Solr似乎在提交时阻止更新请求

Question

我们使用以下自动提交选项运行Solr 3.6的主从设置：

maxDocs：500000

maxTime：600000

我们的索引中有大约500万份文件，占用大约550GB。我们在Amazon EC2 XLarge实例（4个虚拟核心和15GB）上运行主服务器和从服务器。我们没有特别高的写入吞吐量 - 每分钟大约100个新文档。

我们将Jetty用作分配了6GB的容器。

问题是，一旦提交开始，我们所有的更新请求都会开始超时（我们不会对此框执行查询）。提交本身似乎需要大约20-25分钟，在此期间我们无法向Solr添加任何新文档。

以下问题中的一个答案建议使用2个核心，并在完全更新后交换它们。然而，这似乎有点过头了。

Solr requests time out during index update. Perhaps replication a possible solution?

关于为什么Solr似乎阻止请求，我还有什么要看的吗？我乐观地希望配置中有一个“dontBlockUpdateRequestsWhenCommitting”标志，我忽略了......

非常感谢，

Answer 1

根据赏金原因，这里提到的问题是Solr的解决方案：

Solr具有从Solr的4.x版本开始称为SolrCloud的功能。而不是以前的主/从架构，有领导者和复制品。领导者负责索引文档和副本答案查询。系统由Zookeeper管理。如果领导者失败，其中一个副本被选为新领导者。

总而言之，如果您希望自动将SolrCloud的索引过程分开，因为每个分片都有一个领导者，他们负责为分片的文档编制索引。当您向系统发送查询时，将会有一些Solr节点（当然，如果Solr节点多于分片计数），它们不负责索引但是准备回答查询。当您添加更多副本时，您将获得更快的查询结果（但在索引等时会导致更多的入站网络流量。）

Answer 2

对于那些面临类似问题的人，我的问题的原因是我在文档中有太多字段，我使用自动字段* _t，字段数量增长得非常快，当达到一定数量时，它只是生猪solr和承诺将永远。

其次，我花了一些力气做了一个分析，它最终大部分时间都被string.intern（）函数调用消耗，看起来文档中的字段数很重要，当这个数字上升时， string.intern（）似乎变慢了。

solr4源不再使用string.intern（）了。但是大量的领域仍然很容易杀死它。