Question

我们有一个Solr 4.51（Debian）安装，由node.js应用程序填充。两者都驻留在同一台机器上。我们每秒添加大约250到350个文档。 Solr配置为自动提交（1000毫秒软/ 15000毫秒硬）。

在大约100到150秒之后，Solr变得不可用一个长达五秒钟。因此http.request()会返回EADDRNOTAVAIL。与此同时，我们有一个解决方法，重试每500毫秒添加一次文档。因此，经过一次最多10次尝试，Solr再次可用，一切正常（直到下一次休息）。

我们想知道这是否正常。或者所描述的行为可能是由于任何错误配置造成的？

Solr日志文件中有否错误或警告条目。值得注意的是，当不可用时，相应Solr java进程的cpu工作负载从30％下降到几乎为零。

当然我们的node.js应用程序总是等待http.request的答案，所以不应该有任何可能引起任何溢出的并行请求。

Solr制造这些“咖啡休息时间”的原因是什么？

感谢任何提示！

修改

在发生错误时查看Solr日志（启用haviing自动提交）。日志文件sais：

80583779 [commitScheduler-9-thread-1] INFO org.apache.solr.update.UpdateHandler â start commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=true,prepareCommit=false}
80583788 [commitScheduler-9-thread-1] INFO org.apache.solr.search.SolrIndexSearcher â Opening Searcher@1263c036 main
80583789 [commitScheduler-9-thread-1] INFO org.apache.solr.update.UpdateHandler â end_commit_flush
80583789 [searcherExecutor-5-thread-1] INFO org.apache.solr.core.SolrCore â QuerySenderListener sending requests to Searcher@1263c036 main{StandardDirectoryReader(segments_1lv:67657:nrt _opz(4.5.1):C1371694/84779:delGen=1 _p29(4.5.1):C52149/1067:delGen=1 _q0p(4.5.1):C48456 _q0z(4.5.1):C2434 _q19(4.5.1):C2583 _q1j(4.5.1):C3195 _q1t(4.5.1):C2633 _q23(4.5.1):C3319 _q1c(4.5.1):C351 _q2n(4.5.1):C3277 _q2x(4.5.1):C2618 _q2d(4.5.1):C2621 _q2w(4.5.1):C201)}
80583789 [searcherExecutor-5-thread-1] INFO org.apache.solr.core.SolrCore â QuerySenderListener done.
80583789 [searcherExecutor-5-thread-1] INFO org.apache.solr.core.SolrCore â [base] Registered new searcher Searcher@1263c036 main{StandardDirectoryReader(segments_1lv:67657:nrt _opz(4.5.1):C1371694/84779:delGen=1 _p29(4.5.1):C52149/1067:delGen=1 _q0p(4.5.1):C48456 _q0z(4.5.1):C2434 _q19(4.5.1):C2583 _q1j(4.5.1):C3195 _q1t(4.5.1):C2633 _q23(4.5.1):C3319 _q1c(4.5.1):C351 _q2n(4.5.1):C3277 _q2x(4.5.1):C2618 _q2d(4.5.1):C2621 _q2w(4.5.1):C201)}
80593917 [commitScheduler-6-thread-1] INFO org.apache.solr.update.UpdateHandler â start commit{,optimize=false,openSearcher=false,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
80593931 [commitScheduler-6-thread-1] INFO org.apache.solr.core.SolrCore â SolrDeletionPolicy.onCommit: commits: num=2

所以乍一看，看起来Solr在执行软提交时拒绝了http连接。但是，

之前有许多软提交没有拒绝
之后会有很多软提交而不会拒绝
和（最重要的）当在节点的所有http请求中禁用自动提交时，无论如何都会被拒绝（或多或少与启用了aut-commit的阶段相同）。

禁用自动提交的Solr日志文件在这里停止（添加文档时）：

153314 [qtp1112461277-10] INFO org.apache.solr.update.processor.LogUpdateProcessor â [base] webapp=/solr path=/update/json params={commit=false&wt=json} {add=[52c14621fc45c82d4d009155]} 0 0
153317 [qtp1112461277-16] INFO org.apache.solr.update.processor.LogUpdateProcessor â [base] webapp=/solr path=/update/json params={commit=false&wt=json} {add=[52c14621fc45c82d4d009156]} 0 0
153320 [qtp1112461277-17] INFO org.apache.solr.update.processor.LogUpdateProcessor â [base] webapp=/solr path=/update/json params={commit=false&wt=json} {add=[52c14621fc45c82d4d009157]} 0 1
153322 [qtp1112461277-18] INFO org.apache.solr.update.processor.LogUpdateProcessor â [base] webapp=/solr path=/update/json params={commit=false&wt=json} {add=[52c14621fc45c82d4d009158]} 0 0
153325 [qtp1112461277-13] INFO org.apache.solr.update.processor.LogUpdateProcessor â [base] webapp=/solr path=/update/json params={commit=false&wt=json} {add=[52c14621fc45c82d4d009159]} 0 0
153329 [qtp1112461277-19] INFO org.apache.solr.update.processor.LogUpdateProcessor â [base] webapp=/solr path=/update/json params={commit=false&wt=json} {add=[52c14621fc45c82d4d00915a]} 0 1
153331 [qtp1112461277-12] INFO org.apache.solr.update.processor.LogUpdateProcessor â [base] webapp=/solr path=/update/json params={commit=false&wt=json} {add=[52c14621fc45c82d4d00915b]} 0 0
153334 [qtp1112461277-15] INFO org.apache.solr.update.processor.LogUpdateProcessor â [base] webapp=/solr path=/update/json params={commit=false&wt=json} {add=[52c14621fc45c82d4d00915c]} 0 0
153336 [qtp1112461277-11] INFO org.apache.solr.update.processor.LogUpdateProcessor â [base] webapp=/solr path=/update/json params={commit=false&wt=json} {add=[52c14621fc45c82d4d00915d]} 0 0

所以这里没有提示提交或索引可能是Solr拒绝任何（任何！）http请求1-3秒的原因。

EDIT2：

同样值得注意的是，如果我们将root-logging切换到ALL，Solr会变慢（由于更详细的日志记录而显而易见），但错误也会消失。所以不再有拒绝期。这看起来也是一个时间问题...

EDIT3：

与此同时，我发现，Solr的不可用性只会影响我的节点应用程序。虽然不能用于node.js，但我可以向Solr Web Admin发出请求。我还试图从node.js连接到一个不能访问Solr的不同的Web服务器。这样可行！所以这很奇怪，我的node.js应用程序无法访问Solr几秒钟，但任何其他应用程序都可以。任何想法可能是什么原因？

Answer 1

如果您正在进行完整索引，那么使用自动提交是一个坏主意。

发生的事情是在每次硬提交时都会形成一个新的索引文件。并且您的策略显示每15000个文档发生一次提交。这可能每50秒（300 docs / sec）创建一个优化周期，并且在优化期间，solr服务器拒绝提供查询，因为它的最大资源被用于优化，因此如果执行“Big / Bulk / Full INdexing”注释掉自动提交，它会加快你的索引。尝试注释掉大索引的事务日志，因为这些是批量索引方案中的开销

问候

拉杰特

Answer 2

请提供更多数据，

每个索引周期数量为1卷的文档数量。（每分钟的文档数量或任何类似的文档）

2你使用solr的目的是什么（搜索类型NRT或延迟）

3你的solr配置是什么（主从等等及其目的）

我所看到的提交过程是。索引提交solr“Ques”时索引请求，当它被释放时它只是索引它们虽然看起来它已经停止了，但索引仍在继续。

查看缓存的预热计数，我假设您有一个主从配置。因此，对于高速缓存的主预热计数应为零，因为无论如何，您每15秒清除所有高速缓存

其次我觉得你不太可能遇到停止生产系统的问题。因为你会有一个大的索引而休息会是小文件所以在这种情况下合并会有很小的部分，但如果你能回答我提出的问题，我会更好地回答这个问题

问候

拉杰特

Answer 3

最后我找到了答案。这是默认全局http代理的问题。查看完整说明here。

Solr在添加文档时变得不可用

3 个答案: