我们正在使用以下自动提交选项运行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的功能，从Solr的版本开始4.x Solr版本开始。代替以前的主/从架构，有领导者和副本。领导者负责为文档编制索引，副本回答查询。系统由Zookeeper管理。如果一个领导者出现故障，则其中一个副本被选为新的领导者。
总而言之，如果您想自动划分SolrCloud可以的索引过程，因为每个分片都有一个领导者，他们负责为其分片的文档编制索引。当您向系统发送查询时，会有一些 Solr 节点(当然，如果 Solr 节点超过分片计数(不负责索引，但准备回答查询。当您添加更多副本时，您将获得更快的查询结果(但在索引等时会导致更多的入站网络流量(
对于那些面临类似问题的人来说，我问题的原因是文档中的字段太多，我使用了自动字段 *_t，并且字段数量增长非常快，当达到一定数量时，它只是占用 solr 并提交将花费永远。
其次，我花了一些精力做一个分析，它最终大部分时间都被string.intern((函数调用所消耗，似乎文档中的字段数量很重要，当这个数字上升时，string.intern((似乎越来越慢。
solr4 源代码似乎不再使用 string.intern((。但是大量的场仍然很容易扼杀性能。