Как исправить ошибку Java OutOfMemoryError: пространство кучи Java из DataImportHandler? - PullRequest
14 голосов
/ 02 июня 2011

Я пытаюсь импортировать большой набор данных (41 миллион записей) в новый индекс 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

Данные-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: init mem 128 МБ, максимум 512 МБ

Окружающая среда: Solr 3.1 кот 7.0.12 Windows Server 2008 Java: v6 обновление 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. Теперь для другого запуска импорта (ууу ...)

Ответы [ 6 ]

8 голосов
/ 09 июня 2011
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 заканчивается RAM. Многие драйверы JDBC могут по умолчанию извлекать все свои результаты сразу в память. Так что посмотрите, можно ли это настроить, или подумайте об использовании JTDS-драйвера с открытым исходным кодом, который обычно лучше себя ведет в любом случае

Я не верю, что maxfieldlength вам поможет - это повлияет на то, сколько Lucene усекает, но не на то, сколько изначально передается. Другим вариантом является одновременный перенос выделенного фрагмента, скажем, 1 миллиона, с использованием TOP и ROWNUMBER и т. Д. Для подкачки.

1 голос
/ 29 декабря 2015

Для MySQL это работает

Согласно solr wiki,

DataImportHandler предназначен для потоковой передачи строки один за другим. Он передает значение размера выборки (по умолчанию: 500) в Statement # setFetchSize, что некоторые драйверы не соблюдают. Для MySQL добавьте свойство batchSize в конфигурацию источника данных со значением -1. Это передаст 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"/>
1 голос
/ 28 марта 2013

Мне удалось успешно импортировать большую таблицу с помощью jdbc на Sql Server, не сталкиваясь с ошибками нехватки памяти, путем пакетирования запросов вручную. В моём случае 256 партий:

Данные-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-файл CTE, который возвращает байтовые значения 0-255. Это используется для фильтрации дочерней сущности results .

Примечание 1: Условие where (т. Е. CONVERT (varbinary (1), fielda) = $ {batch.BatchId} ) следует настраивать в зависимости от типа и содержимого поля разделения, чтобы разделить результаты на равные партии. например Используйте fielda% 255 = $ {batch.BatchId} , если fielda - это число. В моем случае fielda был уникальным идентификатором, поэтому первого байта было достаточно.

Примечание 2: rootEntity = "false" на объекте партия является обязательным и указывает, что объект партия равен НЕ корневой документ.

1 голос
/ 13 февраля 2013

Эта ветка, кажется, довольно старая ... но кому-то нужна дополнительная информация ..., пожалуйста, посмотрите на следующую ссылку для ответов на описанные выше проблемы нехватки памяти:

http://wiki.apache.org/solr/DataImportHandlerFaq

0 голосов
/ 16 июня 2011

Я обнаружил, что с большими наборами записей все может стать немного волосатым.У вас есть пара вариантов.

Быстрый и наиболее вероятный лучший вариант - выделить больше памяти для системы индексации!Память (по большей части) довольно дешевая.

Другая вещь, которую я мог бы попробовать, это фрагментация данных .

В зависимости от размера ваших "документов" 41MДокументы могут вас раздражать, когда дело доходит до поиска.Вы можете захотеть осколок документов.При использовании DIH я пытаюсь облегчить разбиение с помощью параметра querystring.Вы можете сделать это, ссылаясь на соответствующий параметр, переданный в DHI, используя $ {dataimporter.request.MYPARAMETERNAME} в операторе запроса.

0 голосов
/ 15 июня 2011

Возможно, вам недостаточно настроек Java для этой работы: init mem 128mb, максимум 512mb

Попробуйте это исправление культа груза для OutOfMemoryError: увеличьте размер кучисделайте это -Xmx1024M или больше, если вы можете себе это позволить, и начальные 512M -Xms512M

...