2015-10-06 50 views
1

我们有一个旧的Solr 3.6服务器,复制行为非常奇怪。Solr复制缓慢

看看图像。这就像超级慢。它表示连接速度很慢,但实际上可能并非如此,因为即使几分钟后下载的kb数量也完全没有改变。

此外,您看到419 GB的总下载量是错误的,也就是整个索引,但我们并不是完全复制它。

我可以看到“下载文件”在一秒钟内达到100%,然后剩下的都是等待时间。即使速度更快,等待时间总是在索引移动到下一个版本之前的120秒左右。

它有时会持续很长时间(如5到20分钟),然后突然全部完成。 有时它很快。

我们有这样的复制配置:

<requestHandler name="/replication" class="solr.ReplicationHandler"> 
<lst name="master"> 
<str name="enable">${solr.master.enable:false}</str> 
<str name="replicateAfter">startup</str> 
<str name="replicateAfter">commit</str> 
</lst> 
<lst name="slave"> 
<str name="enable">${solr.slave.enable:false}</str> 
<str name="masterUrl">http://10.20.16.125:8080/solr/replication</str> 
<str name="pollInterval">00:00:60</str> 

enter image description here

+0

使用SOLR 3.1面临同样的问题。你有没有得到任何解决方案? – Shalu

+0

@Shalu - 对于经验,如果您按照以下答案中的建议调整合并因子,则应该解决问题。让我知道事情的后续。 – AR1

回答

1

有几种可能的原因,可能导致这样的问题:

  • 的Java。 lang.OutOfMemoryError在复制过程中发生(为了解决这类问题,请参阅Apache Solr Cookbook中的“如何处理内存不足问题”);
  • 一个常见的段合并,可以由以下原因引起:

至于下一步我建议他们:

  1. 在Solr的服务器验证登录内存溢出或其他有趣的错误的存在。
  2. 验证执行优化的频率(您的代码中是否有触发器?);
  3. 下合并因子为2(<mergeFactor>**2**</mergeFactor>
  4. 尝试<useCompoundFile>true</useCompoundFile>,将告诉Solr的使用所述化合物的索引结构更并且因此将减少创建索引和所需合并的数量的文件数。
  5. 验证是否存在针对Solr/Lucene版本打开的合并策略错误。

一些额外的有趣的信息可以在this answer找到。