postgresql - Apache solr 5.3.1 内存不足

Question

我是 solr 的新手，尽管我花了几天时间在一个拥有大约 117.000.000 个条目的实体上的 postgreSQL 9.4 数据库上运行完整索引。我在具有 16 GB RAM 的 Windows 7 x64 上使用 solr 5.3.1。我不打算将这台机器用作服务器，它只是我正在进行的某种原型(prototype)设计。

我在 JDK x86 上一直收到这个错误，只是以 solr start 启动 solr，没有任何选项。然后我尝试了:solr start -m 2g 这导致 solr 根本不出现solr start -m 1g 使 solr 启动，但在索引了大约 87.000.000 个条目后，它因内存不足错误而终止。

虽然在管理仪表板中我看到 JVM 堆已满，但它在没有任何选项的情况下死机的时间点完全相同。

因此，由于 solr 无论如何都会警告我使用 x64 JDK，所以我使用了 x64 JDK，现在使用 8u65。我用 4g Heap 启动了 solr，然后再次开始完全导入。在 87.000.000 个条目之后，它再次抛出相同的异常。但是堆甚至没有满 (42%)，RAM 或 SWAP 也没有满。

有谁知道造成这种行为的原因是什么？这是我的数据配置

<dataConfig>
<dataSource 
type="JdbcDataSource"
driver="org.postgresql.Driver"
url="jdbc:postgresql://localhost:5432/dbname"
user="user"
password="secret"
readOnly="true" 
autoCommit="false" 
transactionIsolation="TRANSACTION_READ_COMMITTED" 
holdability="CLOSE_CURSORS_AT_COMMIT" />

<entity name="hotel"
query="select * from someview;"
deltaImportQuery = "select * someview where solr_id = '${dataimporter.delta.id}'"
deltaQuery="select * from someview where changed > '${dataimporter.last_index_time}';">

<field name="id" column="id"/>
... etc for all 84 columns

在 solrconfig.xml 中，我定义了一个 RequestProcessorChain 来在索引时生成一个唯一的键，这似乎可行。

在 schema.xml 中，同样有 84 列具有类型、索引和其他属性。

这是我遇到的异常，它们是德语，但第一个是“错误 48”，另一个是“内存不足”

getNext() failed for query 'select * from someview;':org.apache.solr.handler.dataimport.DataImportHandlerException: org.postgresql.util.PSQLException: FEHLER: Speicher aufgebraucht
Detail: Fehler bei Anfrage mit Größe 48.
at org.apache.solr.handler.dataimport.DataImportHandlerException.wrapAndThrow(DataImportHandlerException.java:62)
at org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.hasnext(JdbcDataSource.java:416)
at org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.access$500(JdbcDataSource.java:296)
at org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator$1.hasNext(JdbcDataSource.java:331)
at org.apache.solr.handler.dataimport.EntityProcessorBase.getNext(EntityProcessorBase.java:132)
at org.apache.solr.handler.dataimport.SqlEntityProcessor.nextRow(SqlEntityProcessor.java:74)
at org.apache.solr.handler.dataimport.EntityProcessorWrapper.nextRow(EntityProcessorWrapper.java:243)
at org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:475)
at org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:414)
at org.apache.solr.handler.dataimport.DocBuilder.doFullDump(DocBuilder.java:329)
at org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:232)
at org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:416)
at org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:480)
at org.apache.solr.handler.dataimport.DataImporter$1.run(DataImporter.java:461)
Caused by: org.postgresql.util.PSQLException: FEHLER: Speicher aufgebraucht
Detail: Fehler bei Anfrage mit Größe 48.
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2182)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1911)
at org.postgresql.core.v3.QueryExecutorImpl.fetch(QueryExecutorImpl.java:2113)
at org.postgresql.jdbc2.AbstractJdbc2ResultSet.next(AbstractJdbc2ResultSet.java:1964)
at org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.hasnext(JdbcDataSource.java:408)
... 12 more

提前致谢

Answer 1

正如 MatsLindh 指出的那样，这是一个 JDBC 错误。与此同时，我使用休眠搜索并在同一时间遇到相同的错误(接近 87.000.000 个索引实体)。诀窍是更频繁地提交。

所以在这种情况下，我一次尝试了几种方法并且成功了(不知道哪个选项确实起作用了):

1. set maxDocs for autoCommit in solrconfig.xml to 100.000. I believe that the default setting for committing is something at 15 seconds if no new documents are added, what actually happens all the time, until heap space runs full.
2. Set batchSize for the postrgreSQL JDBC Driver at 100 (Default is 500).
3. Changed the evil 'select * from table' to 'select c1, c2, ..., c85 from table'
4. Updated the JDBC Driver from 9.4.1203 to 9.4.1207
5. Updated Java to 1.8u74

由于 1. 和/或 3.，我认为它有效，我将做一些进一步的测试并更新我的帖子。

当我尝试使用休眠搜索建立索引时，我可以看到为 PostgreSQL Server 分配的 RAM 在提交时被释放，因此 RAM 再也不是问题了。这并没有发生在这里，数据库服务器最终使用了 85 GB RAM，但仍在继续工作。