高亮显示时Solr性能非常慢

我配置了一个Solr4.4.0内核，其中包含约630k文档，原始大小约为10GB。每个字段都会复制到文本字段中，以便查询和突出显示。当我在没有突出显示的情况下执行搜索时，结果大约在100毫秒后返回，但当突出显示打开时，相同的查询需要10-11秒。我还注意到，对于相同的术语，后续的查询持续大约10-11秒

我对该字段的初始配置如下

<field name="text" type="text_general" indexed="true" stored="true"
   multiValued="true"
   omitNorms="true"
   termPositions="true"
   termVectors="true"
   termOffsets="true" />

http://solrtest:8983/solr/Incidents/select?q=error+code&fl=id&wt=json&indent=true&hl=true&hl.fl=text2&hl.useFastVectorHighlighter=true

我所有的研究似乎都没有提供线索来解释为什么精彩表演如此糟糕。一时兴起，我决定看看ommitnorms=true属性是否会有效果，我修改了文本字段，删除了数据，然后从头开始重新加载

<field name="text" type="text_general" indexed="true" stored="true"
   multiValued="true"
   termPositions="true"
   termVectors="true"
   termOffsets="true" />

同样，数据被清除并使用相同的630k文档重新加载，但这次索引大小约为17GB。（由于“文本”字段上的内容重复，因此与预期一样。）

问题是每次运行的性能数字都会回到原来的10-11秒。第一次撤军不是侥幸，就是有别的事情正在发生。我不知道

使用jVisualVM捕获CPU示例显示了以下两种使用大部分CPU的方法

org.apache.lucene.search.vectorhighlight.FieldPhraseList.<init>()    8202 ms (72.6%)
org.eclipse.jetty.util.BlockingArrayQueue.poll()                     1902 ms (16.8%)

org.apache.lucene.search.vectorhighlight.FieldPhraseList.（）8202毫秒（72.6%）
org.eclipse.jetty.util.BlockingArrayQueue.poll（）1902毫秒（16.8%）

我已经看到init方法低至54%，民意调查数字高达30%

有什么想法吗？还有其他地方可以找到瓶颈吗

谢谢

更新

我用相同的数据集做了一系列测试，但配置不同，下面是我的发现…尽管我不理解我的发现

• 快速高亮显示性能要求不设置为true。（不知道规范和突出显示之间有什么关系。）
• 然而，只有当查询和突出显示都针对相同的字段（即df=hl.fl）执行时，这似乎才是正确的。（同样，不知道为什么…）
• 但是，另一个是，仅当针对架构中存在的默认文本字段执行时

下面是我如何测试-->

• 测试是针对大约525000份文件进行的
• 几乎所有字段都复制到多值文本字段
• 在一些测试中，几乎所有字段都被复制到发送多值文本2字段中（该字段与文本相同，只是设置了相反的忽略规范）
• 每次更改配置时，都会停止Solr实例，删除数据文件夹，并启动实例进行备份

我发现-->

• 当仅使用文本字段且当前为时，性能不佳（10秒响应时间）
• 当仅使用文本字段且忽略规范=真不存在时，性能非常好（亚秒响应时间）
• 当text没有not有忽略norms=true和text2没有时，突出显示text的查询以亚秒的时间返回，所有其他的组合导致10-30秒的响应时间
• 当text确实有ommitnorms=true和text2没有时，所有带有突出显示的查询组合都会在7-10秒内返回

---

我很困惑……

我知道这有点过时，但我遇到了同样的问题，我想加入我们的方法

我们正在为一堆二进制文档中的文本编制索引，需要Solr来维护文档以及文本的一些元数据。用户需要根据元数据搜索文档，并在内容中进行全文搜索，以及查看相关内容的突出显示和片段。如果突出显示/删除内容，性能问题会变得更糟t位于每个文件的更深处（e.x.第50页而非第2页）

由于突出显示性能不佳，我们不得不将每个文档拆分为多个solr记录。根据内容字段的长度，我们将其拆分为更小的块，将元数据属性复制到每个记录，并为每个记录分配一个每个文档唯一的id。然后在查询时，我们将搜索所有ese记录并按我们指定的唯一字段进行分组。由于内容字段较小，Solr不必深入每个内容字段，而且从最终用户的角度来看，这是完全透明的；尽管它确实为我们增加了一点索引开销

另外，如果选择这种方法，您可能需要考虑在每个“子文档”之间稍微重叠几秒钟，以确保如果在两秒钟的边界处有短语匹配，它将正确返回。

---

希望能有帮助。

不是答案，但是……你能试试吗？另一个问题是，这需要更少的磁盘空间-根据差异是“~7.8X，用于1000万文档的英文维基百科索引”。但它不支持通配符搜索。此外，还有一些类似的问题。@rchukh-我已经看到了您链接到的支持。这就是我想到使用jvisualvm的原因，发现这两种方法占用了大量CPU。关于另一个highlighter，我也读到了相关内容，但由于没有快速向量为n的逻辑原因

http://solrtest:8983/solr/Incidents/select?q=error+code&fl=id&wt=json&indent=true&hl=true&hl.fl=text2&hl.useFastVectorHighlighter=true

org.apache.lucene.search.vectorhighlight.FieldPhraseList.<init>()    8202 ms (72.6%)
org.eclipse.jetty.util.BlockingArrayQueue.poll()                     1902 ms (16.8%)