Как исправить java OutOfMemoryError: куча Java-памяти из DataImportHandler?
Я пытаюсь импортировать большой набор данных (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 128mb, max 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
EDIT: В настоящее время я запускаю sql-запрос, чтобы узнать наибольшую длину одного поля записи, так как я думаю, что это, вероятно, причина исключения. Кроме того, снова запустить импорт с помощью jconsole для отслеживания использования кучи.
EDIT: прочитайте страницу с показателями эффективности solr. изменение maxFieldLength до 1000000 и изменение ramBufferSizeMB = 256. Теперь для другого запуска импорта (yay...)
Ответы
Ответ 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 усекает, но не сколько изначально было перенесено. Другой вариант - только передать выделение за раз, скажем, 1 миллион, используя TOP и ROWNUMBER, а также для пейджинга.
Ответ 2
Этот поток кажется довольно старым... но кто-то нуждается в дополнительной информации... пожалуйста, посмотрите следующую ссылку для ответов на проблемы с памятью, описанные выше:
http://wiki.apache.org/solr/DataImportHandlerFaq
Ответ 3
Мне удалось успешно импортировать большую таблицу с использованием 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>
Родительский объект пакет является рекурсивным SQL-сервером CTE, который возвращает значения байтов 0-255. Это используется для фильтрации дочернего объекта результатов.
Примечание 1: Условие if (т.е. CONVERT (varbinary (1), fielda) = ${batch.BatchId}) должно быть скорректировано в зависимости от типа и содержимое поля разбиения, чтобы разбивать результаты на равные партии. например Используйте fielda% 255 = ${batch.BatchId}, если fielda - это число. В моем случае fielda был уникальным идентификатором, поэтому первый байт был достаточным.
Примечание 2: Требуется rootEntity = "false" в пакетной сущности и указывает пакет объект НЕ корневой документ.
Ответ 4
Для mysql он работает
В соответствии с wiki wiki,
DataImportHandler предназначен для потоковой передачи строк один за другим. Он передает значение размера выборки (по умолчанию: 500) в Statement # setFetchSize, которое некоторые драйверы не соблюдают. Для MySQL добавьте свойство batchSize в конфигурацию dataSource со значением -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"/>
Ответ 5
Настройки вашей конфигурации java могут быть недостаточными для этого задания: init mem 128mb, max 512mb
Попробуйте это исправление культа для OutOfMemoryError: увеличьте размер кучи
сделайте это -Xmx1024M или более, если вы можете себе это позволить и начальный 512M -Xms512M
Ответ 6
Я обнаружил, что с большими наборами записей все может стать немного волосатым. У вас есть пара вариантов.
Быстрый и наиболее вероятный вариант - выделить больше памяти для системы индексирования! Память (по большей части) довольно дешевая.
Другая вещь, которую я могу попробовать, - chunking data.
В зависимости от размера ваших "документов" документы 41M могут подталкивать вас, когда дело доходит до поиска. Возможно, вы захотите очертить документы. При использовании DIH я пытаюсь облегчить разбиение на разделы с помощью параметра querystring. Вы можете сделать это, указав соответствующий параметр, переданный в DHI, с помощью ${dataimporter.request.MYPARAMETERNAME} в запросе.
