我们使用以下自动提交选项在 Solr 3.6 中运行主从设置：
最大文档数：500000
最大时间：600000
我们的索引中有大约 500 万个文档，占用大约 550GB。我们在 Amazon EC2 XLarge 实例（4 个虚拟内核和 15GB）上同时运行主服务器和从服务器。我们没有特别高的写入吞吐量——每分钟大约 100 个新文档。
我们使用 Jetty 作为分配给它的 6GB 的容器。
问题是一旦开始提交，我们所有的更新请求都会开始超时（我们没有对这个框执行查询）。提交本身似乎需要大约 20-25 分钟，在此期间我们无法向 Solr 添加任何新文档。
以下问题中的一个答案建议使用 2 个内核并在完全更新后交换它们。然而，这似乎有点过头了。
Solr 请求在索引更新期间超时。也许复制是一个可能的解决方案？
关于 Solr 似乎阻止请求的原因，我还有什么需要注意的吗？我乐观地希望配置中有一个我忽略的“dontBlockUpdateRequestsWhenCommitting”标志......
非常感谢，
根据赏金原因，这里提到的问题是 Solr 的解决方案：
Solr 具有称为 SolrCloud 的功能，从4.xSolr 版本开始。代替以前的主/从架构，有领导者和副本。领导者负责索引文档和副本回答查询。系统由 Zookeeper 管理。如果一个领导者宕机，它的一个副本被选为新的领导者。
总而言之，如果您想自动划分对 SolrCloud 来说可以的索引过程，因为每个分片都有一个领导者，他们负责为其分片的文档编制索引。当您向系统发送查询时，将有一些 Solr 节点（当然，如果 Solr 节点超过分片计数）不负责索引但准备好回答查询。当您添加更多副本时，您将获得更快的查询结果（但在索引等时会导致更多的入站网络流量）
对于那些面临类似问题的人来说，我的问题的原因是文档中的字段太多，我使用了自动字段 *_t，并且字段数量增长非常快，当达到一定数量时，它只是hogs solr 和 commit 将永远持续下去。
其次，我花了一些精力进行分析，它最终大部分时间都被 string.intern() 函数调用所消耗，似乎文档中的字段数很重要，当这个数字上升时，string.intern () 似乎越来越慢。
solr4 源似乎不再使用 string.intern() 了。但是大量的字段仍然很容易扼杀性能。