我们正在运行Solr安装（所有标准的jetty环境，只是在架构中添加了一些字段）。
索引大约是80k平均大小的文档（可能是20个字段，每个字段大约100个字符）。
问题是有时请求超时。好吧，他们没有超时服务器端，但他们需要超过10秒，这是我们的应用程序认为它超时。它们是非常简单的查询，通常不会超过80毫秒或更长时间。
它似乎与重建索引相关（我们从数据库收集信息，并在200个文档的块中不断更新索引）。通过我的意思，必要时，如果没有文件更新，索引作业将被发送到睡眠状态。我估计每15-20分钟就会发生一次提交。
我读了solr faqs和东西，似乎这是一个常见的问题，但我没有找到解决办法，只是为了增加超时。
但是网站请求需要＆gt; 10秒是不可接受的。
我该如何解决这个问题？我考虑使用一个installatino进行索引并将其复制到另一个用于查询的实时索引。但这会解决这个问题吗？
你对此有什么想法吗？
答案 0 :(得分：3)
你大部分时间都在正确的轨道上。解决此问题的一种方法是使用第二个核心进行更新，然后在第二个核心完全更新并提交时，使用第一个核心SWAP并使其成为活动核心。
我认为这种方法在“Solr 1.4 Enterprise Search Server”一书中有更详细的描述（这里是一个snippet）
答案 1 :(得分：2)
我认为搜索者会变慢的唯一原因是它是否正在重建其缓存。您是否通过有用的查询来热身您的搜索者？
我的想法......
更新本身不会阻止读取或写入。提交会在刷新写入时阻止写入，但不会读取。刷新一个更新，然后初始化一个新的搜索器，加热，然后换掉旧的搜索器。
如果此时您的搜索超时，可能是您的前几个请求受到严重的IO限制，同时加热后续搜索所依赖的缓存。因此，我想知道你的搜索者是否正在被有用的查询预热。
为了便于讨论，以下是大多数default-ish newSearcher文件中存在的示例solrconfig.xml加温查询：
<listener event="newSearcher" class="solr.QuerySenderListener">
<arr name="queries">
<lst>
<str name="q">solr</str>
<str name="start">0</str>
<str name="rows">10</str>
</lst>
<lst>
<str name="q">rocks</str>
<str name="start">0</str>
<str name="rows">10</str>
</lst>
</arr>
</listener>
也许你还在用这个？ ：）
在这种情况下，复制可能是一种很好的方式。但是，您可能已经有类似的机制可以更好地使用。
答案 2 :(得分：1)
如果您偶尔只看到它，并且文档数量不断增加，您可能会达到合并限制。合并是非常昂贵的，因为旧的段被转换为新的段，并且您的缓存都被转储到启动。
你肯定想要进行主/从设置，SWAP（如上所示）等，以平滑颠簸。