logo标签列表

如何修复DataImportHandler中的Java OutOfMemoryError: Java heap space问题？

javasolrtomcat7
15

我正在尝试将一个大型数据集（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

data-config.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片段：

<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。

环境： Solr 3.1 Tomcat 7.0.12 Windows Server 2008 Java：v6 update 25（构建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性能因素页面。将maxFieldLength更改为1000000并将ramBufferSizeMB更改为256。现在进行另一次导入运行（耶...）

5个回答
8
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截断的数量，但不会影响最初传输的数量。另一个选择是仅一次传输选择的内容，例如使用TOP和ROWNUMBER进行分页。
许多JDBC驱动程序可以默认在内存中一次获取它们的所有结果，这就是为什么我在驱动程序上使用“responseBuffering=adaptive;selectMethod=cursor”来分批流式传输以避免OOM。 - Steve Casey
1
好的，说得也有道理，但是不尝试一下jtds真的完全不行吗？ - MJB
1
一个升级内存和使用JTDS的混合方法奏效了！对于未来遇到此问题的人...放弃使用MS SQL驱动程序！我尝试了增加内存（1.25GB），但失败了。然后，我使用了JTDS驱动程序http://jtds.sourceforge.net，并使用以下连接字符串："jdbc:jtds:sqlserver://mymachine/mydb;useCursors=true;useLOBs=false;"，它运行得非常好。我还发现参数"useLOBs"在我们的导入中至关重要，否则它不会存储大型字符串字段的原始数据，而只会存储"net.sourceforge.jtds.jdbc.ClobImpl@xxxxxx"。 - Steve Casey
1

对于mysql，它可以运行。

根据solr wiki的说法，DataImportHandler被设计为逐行流式传输。它将一个fetch size值(默认值:500)传递给Statement#setFetchSize，而有些驱动程序不支持此方式。对于MySQL，请将batchSize属性添加到dataSource配置中，其值为-1。这将向驱动程序传递Integer.MIN_VALUE作为fetch size，并防止出现大型表时内存不足的情况。

应该像这样:

<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的。 - Steve Casey
1

我成功地使用jdbc将一个大表导入到Sql Server中，通过手动分批查询来避免内存不足错误。在我的情况下，分为了256个批次：

data-config.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字节值。这用于过滤子实体结果(results)。 注意1: where条件(即CONVERT(varbinary(1),fielda) = ${batch.BatchId})应根据分区字段的类型和内容进行调整，以将结果分成相等的批次。例如，如果fielda是数字，则使用fielda % 255 = ${batch.BatchId}。在我的情况下，fielda是唯一标识符，因此第一个字节就足够了。 注意2：batch实体上的rootEntity="false"是必需的，并指示batch实体不是根文档。
0
你的Java配置设置可能不足以完成这项工作：初始内存为128MB，最大内存为512MB。
尝试使用以下“模拟神秘仪式”的解决方法来解决OutOfMemoryError问题：增加堆大小，将其设置为-Xmx1024M或更高（如果您负担得起），并将初始大小设置为512M -Xms512M。
没错，这是最简单的事情。我也会尝试使用MJB建议的JTDS。 - Steve Casey
0

我发现在处理大型记录集时可能会变得有些棘手。你有几个选择。

快速而最好的选择是为索引系统分配更多内存！（大部分情况下）内存相当便宜。

另一件事是我可能会尝试将数据分块。

根据您的“文档”大小，4100万个文档在搜索时可能会拖慢您的速度。您可能需要对文档进行分片。在使用DIH时，我尝试使用查询字符串参数来促进分区。您可以通过在查询语句中引用传递到DHI中的适当参数${dataimporter.request.MYPARAMETERNAME}来实现此目的。

分块(chunking)很有趣，但似乎是一项繁重且过度的工作。我很好奇编写这个包装 API 花了多长时间？或者你是否有兴趣开源/在 gist 上分享它？ - Steve Casey
无法开源它...需要大约4小时的实际工作来编写包装器。 - Marty Trenouth
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接