索引时 Apache SOLR 3.5 挂起

Posted 2023-03-06

【中文标题】索引时 Apache SOLR 3.5 挂起

【英文标题】：Apache SOLR 3.5 hangs when indexing

【发布时间】：2012-04-03 12:50:45

【问题描述】：

我正在尝试为大约 150 万个节点的 drupal 站点建立索引。大多数是简单的节点，大约 100k 节点的大小更大（使用 tika 处理的 pdf 文档）。

我已经尝试过多次索引，但它总是以同样的方式失败：在索引几天后，SOLR 因高负载和内存使用率而崩溃/挂起（不是在寻找最大吞吐量本身）。首先，我将安装移动到一个更大的盒子，从 2 cpu/2GB 内存到 8 核 16GB 内存。这解决了一段时间的问题，但现在情况几乎相同。我能够索引大约 50 万个节点。

Java 使用的内存远远超过堆大小（当前为 8000M）（大量交换） 负载在 3.0 左右（对于小盒子和大盒子） Solr 没有响应索引。搜索很慢但可能。管理界面是响应式的

重启 SOLR 会暂时解决这个问题，但它总是会回来。

在崩溃期间查询索引大小时，我注意到目录大小波动很大。启动 SOLR 后，目录大约为 6.5，并且在再次下降到 6.5 GB 之前可以达到 13GB。这一直在重复。

我添加了注销内存错误的说明，但这并没有为我提供任何日志。

我正在使用 drupal 6 的标准 SOLR 配置。我使用了不同的合并因子，但这似乎对解决问题没有任何帮助。

有人有想法吗？如果您需要更多信息，我会尽快回复！

目前在我的日志中： 线程“Lucene Merge Thread #0”org.apache.lucene.index.MergePolicy$MergeException 中的异常：java.io.FileNotFoundException：/usr/local/solr35/example/multicore/mydivp/data/index/_1bm.fnm（否这样的文件或目录） 在 org.apache.lucene.index.ConcurrentMergeScheduler.handleMergeException（ConcurrentMergeScheduler.java:517） 在 org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:482) 引起：java.io.FileNotFoundException：/usr/local/solr35/example/multicore/mydivp/data/index/_1bm.fnm（没有这样的文件或目录） 在 java.io.RandomAccessFile.open（本机方法） 在 java.io.RandomAccessFile.(RandomAccessFile.java:233) 在 org.apache.lucene.store.MMapDirectory.openInput(MMapDirectory.java:214) 在 org.apache.lucene.store.FSDirectory.openInput(FSDirectory.java:345) 在 org.apache.lucene.index.FieldInfos.(FieldInfos.java:74) 在 org.apache.lucene.index.SegmentCoreReaders.(SegmentCoreReaders.java:73) 在 org.apache.lucene.index.SegmentReader.get(SegmentReader.java:115) 在 org.apache.lucene.index.IndexWriter$ReaderPool.get(IndexWriter.java:705) 在 org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:4400) 在 org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3940) 在 org.apache.lucene.index.ConcurrentMergeScheduler.doMerge（ConcurrentMergeScheduler.java:388） 在 org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:456) 2012-04-03 14:26:25.409:INFO::Shutdown hook 完成

亲切的问候， 布拉姆·荣根

2012-04-06 更新

它仍然不工作.. 检查我的 data/index/ 目录显示 Solr 一直在重建/合并.. 一个段被构建，一旦完成，前一个被删除并且 Solr 再次启动，即使没有新文档是添加。另一个奇怪的事情是 .fdt 文件并没有增长，即使 Solr 状态表明索引了大约 300k 更多的文档。目录中最大的 .fdt 文件永远不会超过 4.9GB。

有什么想法吗？

【问题讨论】：

磁盘空间使用量的变化是正常的。当索引段变得太大时，Solr 会自动合并它们。内存不足错误应该已经记录到主 servlet 容器日志中，对于 Tomcat 的 catalina.out 或对于 Jetty 的 jetty.log。什么版本的 Java？

你误解了 Java 如何直到内存，the heap isn't what the JVM actually uses, it is much more complicated than that。

我正在使用最新的 java 运行 ubuntu 10.04：java 版本 "1.6.0_20" OpenJDK Runtime Environment (IcedTea6 1.9.13) (6b20-1.9.13-0ubuntu1~10.04.1) OpenJDK 64 -Bit Server VM (build 19.0-b09, mixed mode) 在我在 CentOS 上运行之前.. 我​​可能误解了 Java 使用内存的方式，但目前我分配给 -XmX 的值并不重要，JVM 是吃掉所有物理内存和交换杀死性能；）

【参考方案1】：

各位，

我已将 MergePolicy 更改为 LogByteSizeMergePolicy 并将 MergeScheduler 更改为 ConcurrentMergeScheduler，这似乎可以解决问题。仍然不完全确定发生了什么，但我们已经恢复运行；）

谢谢！

【参考方案2】：

此博客可能有助于了解性能因素（该博客更关注查询）和合并策略

http://www.nickveenhof.be/blog/upgrading-apache-solr-14-35-and-its-implications

另外，您的 Solr 和 Drupal 是否在同一台服务器上？

额外信息，建议您在使用 logbytemerge 或默认值时将 luceneMatchVersion 设置为最新的 Lucene_35。新版本的 lucene 也应该有内存泄漏修复：

<?xml version="1.0" encoding="UTF-8" ?>
<config name="my_config">
  <!-- Controls what version of Lucene various components of Solr
       adhere to.  Generally, you want to use the latest version to
       get all bug fixes and improvements. It is highly recommended
       that you fully re-index after changing this setting as it can
       affect both how text is indexed and queried.
    -->
  <luceneMatchVersion>LUCENE_35</luceneMatchVersion>
  <abortOnConfigurationError>$solr.abortOnConfigurationError:true</abortOnConfigurationError>
  <indexDefaults>
    <useCompoundFile>false</useCompoundFile>
    <mergeFactor>10</mergeFactor>
    <!-- Tell Lucene when to flush documents to disk.
    Giving Lucene more memory for indexing means faster indexing at the cost of more RAM
    If both ramBufferSizeMB and maxBufferedDocs is set, then Lucene will flush based on whichever limit is hit first.
    -->
    <ramBufferSizeMB>32</ramBufferSizeMB>
    <maxMergeDocs>2147483647</maxMergeDocs>
    <maxFieldLength>20000</maxFieldLength>
    <writeLockTimeout>1000</writeLockTimeout>
    <commitLockTimeout>10000</commitLockTimeout>
    <!--
     Expert:
     The Merge Policy in Lucene controls how merging is handled by Lucene.  The default in 2.3 is the LogByteSizeMergePolicy, previous
     versions used LogDocMergePolicy.

     LogByteSizeMergePolicy chooses segments to merge based on their size.  The Lucene 2.2 default, LogDocMergePolicy chose when
     to merge based on number of documents

     Other implementations of MergePolicy must have a no-argument constructor
     -->
    <mergePolicy>org.apache.lucene.index.LogByteSizeMergePolicy</mergePolicy>
...

【讨论】：

您好，尼克，感谢您的回答！ Solr 和 Drupal 在不同的服务器上运行。我怀疑它与合并策略有关，但我不知道是什么.. 我重新启动了 SOLR，这意味着它又运行了 20 个小时.. 现在它正在创建新的 .ftd 并删除旧的..跨度>

嗨，实际上我已经在配置中添加了 LUCENE_35，没有帮助:(

好吧，尝试了不同的合并策略，但每次我最大的 .fdt 文件达到 4.9GB Solr 时都会崩溃 :( 现在多次达到此限制.. 有什么想法吗？

切换到sun JRE但无济于事.. :(