如何修复 java OutOfMemoryError：来自 DataImportHandler 的 Java 堆空间？答案

【问题标题】：How to fix java OutOfMemoryError: Java heap space from DataImportHandler?如何修复 java OutOfMemoryError：来自 DataImportHandler 的 Java 堆空间？
【发布时间】：2011-09-06 17:14:33
【问题描述】：

我正在尝试将大型数据集（4100 万条记录）导入新的 Solr 索引。我已经设置了核心，它可以工作，我插入了一些测试文档，它们可以工作。我已经如下设置了 data-config.xml，然后开始完全导入。大约12小时后！导入失败。

文档大小可能会变得非常大，错误可能是由于文档（或字段）过大，还是由于进入 DataImportHandler 的数据量大？

我怎样才能让这个令人沮丧的导入任务正常工作！？！

我已经在下面包含了tomcat错误日志。

如果我遗漏了任何信息，请告诉我！

日志：

Jun 1, 2011 5:47:55 PM org.apache.solr.handler.dataimport.JdbcDataSource$1 call
INFO: Creating a connection for entity results with URL: jdbc:sqlserver://myserver;databaseName=mydb;responseBuffering=adaptive;selectMethod=cursor
Jun 1, 2011 5:47:56 PM org.apache.solr.handler.dataimport.JdbcDataSource$1 call
INFO: Time taken for getConnection(): 1185
Jun 1, 2011 5:48:02 PM org.apache.solr.core.SolrCore execute
INFO: [results] webapp=/solr path=/dataimport params={command=full-import} status=0 QTime=0
...
Jun 2, 2011 5:16:32 AM org.apache.solr.common.SolrException log
SEVERE: Full Import failed:org.apache.solr.handler.dataimport.DataImportHandlerException: java.lang.OutOfMemoryError: Java heap space
    at org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:664)
    at org.apache.solr.handler.dataimport.DocBuilder.doFullDump(DocBuilder.java:267)
    at org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:186)
    at org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:353)
    at org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:411)
    at org.apache.solr.handler.dataimport.DataImporter$1.run(DataImporter.java:392)
Caused by: java.lang.OutOfMemoryError: Java heap space
    at java.lang.StringCoding$StringDecoder.decode(Unknown Source)
    at java.lang.StringCoding.decode(Unknown Source)
    at java.lang.String.<init>(Unknown Source)
    at java.lang.String.<init>(Unknown Source)
    at com.microsoft.sqlserver.jdbc.DDC.convertStreamToObject(DDC.java:419)
    at com.microsoft.sqlserver.jdbc.ServerDTVImpl.getValue(dtv.java:1974)
    at com.microsoft.sqlserver.jdbc.DTV.getValue(dtv.java:175)
    at com.microsoft.sqlserver.jdbc.Column.getValue(Column.java:113)
    at com.microsoft.sqlserver.jdbc.SQLServerResultSet.getValue(SQLServerResultSet.java:1982)
    at com.microsoft.sqlserver.jdbc.SQLServerResultSet.getValue(SQLServerResultSet.java:1967)
    at com.microsoft.sqlserver.jdbc.SQLServerResultSet.getObject(SQLServerResultSet.java:2256)
    at com.microsoft.sqlserver.jdbc.SQLServerResultSet.getObject(SQLServerResultSet.java:2265)
    at org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.getARow(JdbcDataSource.java:286)
    at org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.access$700(JdbcDataSource.java:228)
    at org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator$1.next(JdbcDataSource.java:266)
    at org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator$1.next(JdbcDataSource.java:260)
    at org.apache.solr.handler.dataimport.EntityProcessorBase.getNext(EntityProcessorBase.java:78)
    at org.apache.solr.handler.dataimport.SqlEntityProcessor.nextRow(SqlEntityProcessor.java:75)
    at org.apache.solr.handler.dataimport.EntityProcessorWrapper.nextRow(EntityProcessorWrapper.java:238)
    at org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:591)
    ... 5 more

Jun 2, 2011 5:16:32 AM org.apache.solr.update.DirectUpdateHandler2 rollback
INFO: start rollback
Jun 2, 2011 5:16:44 AM org.apache.solr.update.DirectUpdateHandler2 rollback
INFO: end_rollback

数据配置.xml：

<dataConfig> 
  <dataSource type="JdbcDataSource" 
        driver="com.microsoft.sqlserver.jdbc.SQLServerDriver" 
        url="jdbc:sqlserver://myserver;databaseName=mydb;responseBuffering=adaptive;selectMethod=cursor"   
        user="sa" 
        password="password"/> 
  <document> 
    <entity name="results" query="SELECT fielda, fieldb, fieldc FROM mydb.[dbo].mytable WITH (NOLOCK)"> 
      <field column="fielda" name="fielda"/><field column="fieldb" name="fieldb"/><field column="fieldc" name="fieldc"/> 
    </entity> 
  </document> 
</dataConfig>

solrconfig.xml sn-p:

<indexDefaults>
    <useCompoundFile>false</useCompoundFile>
    <mergeFactor>25</mergeFactor>
    <ramBufferSizeMB>128</ramBufferSizeMB>
    <maxFieldLength>100000</maxFieldLength>
    <writeLockTimeout>10000</writeLockTimeout>
    <commitLockTimeout>10000</commitLockTimeout>
  </indexDefaults>
  <mainIndex>
    <useCompoundFile>false</useCompoundFile>
    <ramBufferSizeMB>128</ramBufferSizeMB>
    <mergeFactor>25</mergeFactor>
     <infoStream file="INFOSTREAM.txt">true</infoStream>
  </mainIndex>

Java 配置设置：初始化内存 128mb，最大 512mb

环境：溶胶 3.1 Tomcat 7.0.12 视窗服务器 2008 java: v6 更新 25 (build 1.6.0_25-b06) （数据来自：sql 2008 r2）

/admin/stats.jsp - DataImportHandler
    Status : IDLE
    Documents Processed : 2503083
    Requests made to DataSource : 1
    Rows Fetched : 2503083
    Documents Deleted : 0
    Documents Skipped : 0
    Total Documents Processed : 0
    Total Requests made to DataSource : 0
    Total Rows Fetched : 0
    Total Documents Deleted : 0
    Total Documents Skipped : 0
    handlerStart : 1306759913518
    requests : 9
    errors : 0

编辑：我目前正在运行一个 sql 查询来找出最大的单个记录的字段长度，因为我认为这可能是异常的原因。此外，使用 jconsole 再次运行导入以监控堆使用情况。

编辑：阅读solr performance factors page。将 maxFieldLength 更改为 1000000 并更改 ramBufferSizeMB = 256。现在进行另一个导入运行（耶...）

【问题讨论】：

标签： java solr tomcat7

【解决方案1】：

Caused by: java.lang.OutOfMemoryError: Java heap space
    at java.lang.StringCoding$StringDecoder.decode(Unknown Source)
    at java.lang.StringCoding.decode(Unknown Source)
    at java.lang.String.<init>(Unknown Source)
    at java.lang.String.<init>(Unknown Source)
    at com.microsoft.sqlserver.jdbc.DDC.convertStreamToObject(DDC.java:419)

很明显，MS JDBC 驱动程序内存不足。许多 JDBC 驱动程序可以默认一次在内存中获取所有结果。所以看看这是否可以调整或考虑使用开源 JTDS 驱动程序，它通常表现更好

我不相信 maxfieldlength 会帮助你 - 这会影响 Lucene 截断的数量，但不会影响最初传输的数量。另一种选择是一次只传输一个选择，比如 100 万个，使用 TOP 和 ROWNUMBER 等进行分页。

【讨论】：

“许多 JDBC 驱动程序可以默认一次在内存中获取所有结果” - 这就是为什么我在驱动程序上设置了 'responseBuffering=adaptive;selectMethod=cursor' 以分批流式传输以避免 OOM。
好吧，很公平，但是不给 jtds 一个机会是绝对不行的吗？
增加内存和 JTDS 的组合奏效了！对于将来发现此问题的人...转储 MS SQL 驱动程序！我尝试了更多内存（1.25gb），但失败了。然后我使用以下连接字符串设置 JTDS 驱动程序jtds.sourceforge.net：“jdbc:jtds:sqlserver://mymachine/mydb;useCursors=true;useLOBs=false;”它工作得很好。我还发现参数 'useLOBs' 在我们的导入中很重要，否则它不会存储大字符串字段的原始数据，而是只存储 'net.sourceforge.jtds.jdbc.ClobImpl@xxxxxx'

【解决方案2】：

通过手动批处理查询，我能够成功地将使用 jdbc 的大型表导入 Sql Server，而不会遇到内存不足错误。就我而言，分 256 批：

数据配置.xml：

<dataConfig> 
  <dataSource  
      type="JdbcDataSource" 
      driver="com.microsoft.sqlserver.jdbc.SQLServerDriver"
      url="jdbc:sqlserver://myserver;databaseName=mydb;responseBuffering=adaptive;selectMethod=cursor"   
      user="sa" 
      password="password" 
      autoCommit="true" 
      batchSize="10000" /> 
  <document> 
    <entity 
        name="batch"
        query="
          with Batch as (
            select 0 BatchId
            union all 
            select BatchId + 1
            from Batch
            where BatchId < 255
          ) 
          select BatchId FROM Batch OPTION (MAXRECURSION 500)
        "
        dataSource="JdbcDataSource"
        rootEntity="false">
      <entity name="results" query="SELECT fielda, fieldb, fieldc FROM mydb.[dbo].mytable WITH (NOLOCK) WHERE CONVERT(varbinary(1),fielda) = ${batch.BatchId}"> 
        <field column="fielda" name="fielda"/><field column="fieldb" name="fieldb"/><field column="fieldc" name="fieldc"/> 
      </entity> 
    </entity> 
  </document> 
</dataConfig>

父实体batch是一个递归的sql server CTE，返回字节值0-255。这用于过滤子实体结果。

注意 1： where 条件（即 CONVERT(varbinary(1),fielda) = ${batch.BatchId} ）应根据类型进行调整和分区字段的内容，以便将结果分成相等的批次。例如如果 fielda 是数字，则使用 fielda % 255 = ${batch.BatchId}。在我的例子中 fielda 是一个唯一标识符，所以第一个字节就足够了。

注意2：batch实体上的rootEntity="false"为必填项，表示batch实体不是根文档。

【讨论】：

【解决方案3】：

对于mysql，它可以工作

根据 solr wiki，

DataImportHandler 旨在逐行流式传输。它将获取大小值（默认值：500）传递给某些驱动程序不支持的 Statement#setFetchSize。对于 MySQL，将 batchSize 属性添加到值为 -1 的 dataSource 配置中。这会将 Integer.MIN_VALUE 作为获取大小传递给驱动程序，并防止其因大型表而出现内存不足。

应该是这样的：

<dataSource type="JdbcDataSource" name="ds-2" driver="com.mysql.jdbc.Driver" url="jdbc:mysql://localhost:8889/mysqldatabase" batchSize="-1" user="root" password="root"/>

【讨论】：

嗨，最初的问题是针对 MS SQL

【解决方案4】：

您的 java 配置设置可能不足以完成这项工作：init mem 128mb, max 512mb

试试这个针对 OutOfMemoryError 的货物狂热修复：增加堆大小如果你能负担得起的话，让它 -Xmx1024M 或更多，最初的 512M -Xms512M

【讨论】：

是的。这是最简单的事情。也会尝试按照 MJB 的建议使用 JTDS

【解决方案5】：

我发现，对于大型记录集，事情会变得有点棘手。你确实有几个选择。

快速且最可能的最佳选择是为索引系统分配更多内存！内存（大部分）非常便宜。

我可能会尝试的另一件事是chunking the data。

根据您的“文档”大小，41M 文档可能会在搜索时让您陷入困境。您可能想要对文档进行分片。使用 DIH 时，我尝试使用查询字符串参数来促进分区。您可以通过在查询语句中使用 ${dataimporter.request.MYPARAMETERNAME} 引用传递给 DHI 的适当参数来做到这一点。

【讨论】：

分块很有趣，但似乎工作量很大/矫枉过正。我很好奇围绕它编写包装api需要多长时间？或者如果你对开源/gist 感兴趣？
不能开源它...大约 4 小时的实际工作来编写包装器