Come assicurarsi che Solr/Lucene non morirà con java.lang.OutOfMemoryError?

Question

Sono davvero perplesso perché continua a morire con java.lang.OutOfMemoryError durante l'indicizzazione anche se ha qualche GB di memoria.

Esiste una ragione fondamentale per cui è necessario il tweaking manuale dei parametri di configurazione/jvm invece di capire quanta memoria è disponibile e limitarsi a tale? Nessun altro programma, tranne Solr, ha mai avuto questo tipo di problema.

Sì, posso mantenere il tweaking della dimensione dell'heap JVM ogni volta che si verificano tali arresti anomali, ma è tutto così indietro.

Ecco traccia dello stack delle più recenti tale incidente nel caso in cui è rilevante:

SEVERE: java.lang.OutOfMemoryError: Java heap space 
    at java.util.Arrays.copyOfRange(Arrays.java:3209) 
    at java.lang.String.<init>(String.java:216) 
    at org.apache.lucene.index.TermBuffer.toTerm(TermBuffer.java:122) 
    at org.apache.lucene.index.SegmentTermEnum.term(SegmentTermEnum.java:169) 
    at org.apache.lucene.search.FieldCacheImpl$StringIndexCache.createValue(FieldCacheImpl.java:701) 
    at org.apache.lucene.search.FieldCacheImpl$Cache.get(FieldCacheImpl.java:208) 
    at org.apache.lucene.search.FieldCacheImpl.getStringIndex(FieldCacheImpl.java:676) 
    at org.apache.lucene.search.FieldComparator$StringOrdValComparator.setNextReader(FieldComparator.java:667) 
    at org.apache.lucene.search.TopFieldCollector$OneComparatorNonScoringCollector.setNextReader(TopFieldCollector.java:94) 
    at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:245) 
    at org.apache.lucene.search.Searcher.search(Searcher.java:171) 
    at org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:988) 
    at org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:884) 
    at org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:341) 
    at org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:182) 
    at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:195) 
    at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) 
    at org.apache.solr.core.SolrCore.execute(SolrCore.java:1316) 
    at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338) 
    at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241) 
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) 
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) 
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) 
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) 
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) 
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) 
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) 
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) 
    at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845) 
    at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) 
    at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) 
    at java.lang.Thread.run(Thread.java:619) 

Answer 1

Guardando la traccia dello stack, sembra che si sta eseguendo una ricerca, e l'ordinamento per un campo. Se hai bisogno di ordinare per un campo, internamente Lucene ha bisogno di caricare tutti i valori di tutti i termini nel campo in memoria. Se il campo contiene molti dati, è molto probabile che si possa esaurire la memoria.

Answer 2

un ipotesi, i documenti che si indicizzazione sono molto grandi

Lucene per default indicizza solo i primi 10.000 termini di un documento per evitare errori OutOfMemory, è possibile superare questo limite vedere setMaxFieldLength

Inoltre, si potrebbe chiamare optimize() e chiudere non appena si è fatto con l'elaborazione con Indexwriter()

un modo preciso è al profilo e trovare il collo di bottiglia =]

Answer 3

io non sono sicuro che ci è un modo costante per assicurarti di non imbatterti in OutOfMemoryExceptions con Lucene. Il problema che stai affrontando è relativo all'utilizzo di FieldCache. Dall'API Lucene "Mantiene le cache dei valori dei termini.". Se i tuoi termini superano la quantità di memoria allocata alla JVM otterrai l'eccezione.

I documenti vengono ordinati "all'indirizzo org.apache.lucene.search.FieldComparator $ StringOrdValComparator.setNextReader (FieldComparator.java:667)", che occuperà tutta la memoria necessaria per memorizzare i termini ordinati per l'indice.

Avrete bisogno di rivedere le dimensioni proiettate dei campi che sono ordinabili e regolare le impostazioni della JVM di conseguenza.

Answer 4

Si sta utilizzando il post.jar per indicizzare i dati? Questo jar ha un bug in solr1.2/1.3. Penso (ma non conosco i dettagli). La nostra azienda ha risolto questo problema internamente e dovrebbe essere corretto anche nell'ultimo trunk solr1.4/1.5.

Answer 5

stavo usando questo Java:

$ java -version 
java version "1.6.0" 
OpenJDK Runtime Environment (build 1.6.0-b09) 
OpenJDK 64-Bit Server VM (build 1.6.0-b09, mixed mode) 

Quale era a corto di spazio di heap, ma poi ho aggiornato a questo Java:

$ java -version 
java version "1.6.0_24" 
Java(TM) SE Runtime Environment (build 1.6.0_24-b07) 
Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode) 

E ora funziona bene, su un enorme insieme di dati , con molte sfaccettature a termine.

Answer 6

Per me ha funzionato dopo il riavvio del server Tomcat.

Answer 7

• passare a C: \ Bitnami \ solr-4.7.2-0 \ apache-Solr script \
• aprono serviceinstall.bat (con Notepad ++ o un altro programma)
• aggiungere o aggiornare le seguenti proprietà: - ++ = JvmOptions -Xms1024M ++ JvmOptions = Xmx1024m
  • dal prompt dei comandi in quella finestra, eseguire serviceinstall.bat RIMUOVERE
  • quindi eseguire serviceinstall.bat INSTALLARE
  • speranza che helpw!

Answer 8

una vecchia questione, ma da quando mi sono imbattuto su di esso:

1. The String Campo cache è molto più compatta da Lucene 4.0. Quindi molto lotto può entrare.
2. Field Cache è una struttura in memoria. Quindi non può impedire OOME.
3. Per i campi che necessitano di fascicolazione o sfaccettatura, è necessario provare DocValues ​​per risolvere questo problema. DocValues ​​funziona con valori di stringa numerici e non analizzati. E presumo che molti casi d'uso di smistamento/sfaccettatura abbiano uno di questi tipi di valore.