Apache SOLR 3.5 hängt beim Indexieren

Question

Ich versuche, eine Drupal-Website mit etwas rund 1,5 Millionen Knoten zu indizieren. Meist einfache Knoten, ca. 100k Knoten sind größer (pdf-Dokumente mit Tika bearbeitet).

Ich habe es schon mehrfach probiert und es schlägt immer auf die gleiche Art und Weise: SOLR stürzt ab/hängt mit hoher Auslastung und Speicherauslastung nach mehreren Tagen der Indexierung (nicht auf maximalen Durchsatz per se). Zuerst habe ich die Installation auf eine größere Box verschoben, von 2 CPU/2 GB Speicher auf 8 Speicher 16 GB. Dies behob das Problem für eine Weile, aber jetzt ist die Situation fast identisch. Ich bin in der Lage, etwa 500.000 Knoten zu indizieren.

Java verwendet Weg, um mehr Speicher als die Heap-Größe (derzeit 8000M) (viel Swapping) Last ist rund 3,0 (für den kleinen und großen Kasten) Solr nicht für die Indizierung reagiert. Das Suchen ist langsam aber möglich. Admin-Schnittstelle reagiert

Neustart SOLR behebt das Problem für eine Weile, aber es kommt immer wieder zurück.

Beim Abfragen der Indexgröße während eines Absturzes bemerke ich, dass die Verzeichnisgröße stark schwankt. Nach dem Start von SOLR ist das Verzeichnis etwa 6,5 ​​und arbeitet bis zu 13 GB, bevor es wieder auf 6,5 GB fällt. Das wiederholt sich.

Ich habe die Anweisungen zum Abmelden von Speicherfehlern hinzugefügt, aber dies liefert mir keine Protokolle.

Ich verwende die Standard-SOLR-Konfiguration für Drupal 6. Ich habe verschiedene Mergefactors verwendet, aber das scheint nichts zu tun, um das Problem zu beheben.

Wer mit Ideen? Wenn Sie mehr Informationen benötigen, werde ich versuchen, so schnell wie möglich zu reagieren!

Dies ist in meinem Protokoll zur Zeit: Exception in thread "Lucene Thread # Merge 0" org.apache.lucene.index.MergePolicy $ MergeException: java.io.FileNotFoundException:/usr/local/solr35/example /multicore/mydivp/data/index/_1bm.fnm (Keine solche Datei oder Verzeichnis) bei org.apache.lucene.index.ConcurrentMergeScheduler.handleMergeException (ConcurrentMergeScheduler.java:517) bei org.apache.lucene.index.ConcurrentMergeScheduler $ MergeThread.run (ConcurrentMergeScheduler.java:482) Verursacht von: java.io.FileNotFoundException: /usr/local/solr35/example/multicore/mydivp/data/index/_1bm.fnm (Keine solche Datei oder Verzeichnis) bei java.io.RandomAccessFile.open (Native Methode) bei java.io.RandomAccessFile. (RandomAcc essFile.java:233) bei org.apache.lucene.store.MMapDirectory.openInput (MMapDirectory.java:214) bei org.apache.lucene.store.FSDirectory.openInput (FSDirectory.java:345) bei org. apache.lucene.index.FieldInfos. (FieldInfos.java:74) bei org.apache.lucene.index.SegmentCoreReaders. (SegmentCoreReaders.java:73) bei org.apache.lucene.index.SegmentReader.get (SegmentReader. java: 115) bei org.apache.lucene.index.IndexWriter $ ReaderPool.get (IndexWriter.java:705) bei org.apache.lucene.index.IndexWriter.mergeMiddle (IndexWriter.java:4400) bei org. apache.lucene.index.IndexWriter.merge (IndexWriter.java:3940) bei org.apache.lucene.index.ConcurrentMergeScheduler.doMerge (ConcurrentMergeScheduler.java:388) bei org.apache.lucene.index.ConcurrentMergeScheduler $ MergeThread.run (ConcurrentMergeScheduler.java:456) 2012-04-03 14:26:25.409: INFO :: Shutdown Haken komplett

Mit freundlichen Grüßen, Bram Rongen

-Update 2012-04-06

Es ist immer noch nicht funktioniert .. Inspizieren meine Daten/index/Verzeichnis Solr zeigt hält Wiederaufbau/Zusammenführung .. Ein Segment wird erstellt und sobald das erledigt ist, wird das vorherige gelöscht und Solr startet erneut, auch wenn keine neuen Dokumente hinzugefügt werden. Eine weitere seltsame Sache ist, dass die .fdt-Datei nicht wächst, obwohl der Solr-Status angibt, dass etwa 300.000 Dokumente mehr indiziert sind. Die größte .fdt-Datei im Verzeichnis ist nie größer als 4,9 GB.

Irgendwelche Gedanken?

Answer 1

Dieses Blog könnte helfen, die Leistungsfaktoren zu verstehen (das Blog ist fokussierter auf Abfragen) und die Verschmelzungspolitik

http://www.nickveenhof.be/blog/upgrading-apache-solr-14-35-and-its-implications

Auch ist Ihre Solr und Drupal auf dem gleichen Server?

Zusätzliche Informationen, es wird empfohlen, dass Sie luceneMatchVersion auf den neuesten Lucene_35 setzen, wenn Sie logbytemerge oder die Standardwerte verwenden. Die neue Version von Lucene sollte auch Speicherverlust Behebungen haben:

<?xml version="1.0" encoding="UTF-8" ?> 
<config name="my_config"> 
    <!-- Controls what version of Lucene various components of Solr 
     adhere to. Generally, you want to use the latest version to 
     get all bug fixes and improvements. It is highly recommended 
     that you fully re-index after changing this setting as it can 
     affect both how text is indexed and queried. 
    --> 
    <luceneMatchVersion>LUCENE_35</luceneMatchVersion> 
    <abortOnConfigurationError>${solr.abortOnConfigurationError:true}</abortOnConfigurationError> 
    <indexDefaults> 
    <useCompoundFile>false</useCompoundFile> 
    <mergeFactor>10</mergeFactor> 
    <!-- Tell Lucene when to flush documents to disk. 
    Giving Lucene more memory for indexing means faster indexing at the cost of more RAM 
    If both ramBufferSizeMB and maxBufferedDocs is set, then Lucene will flush based on whichever limit is hit first. 
    --> 
    <ramBufferSizeMB>32</ramBufferSizeMB> 
    <maxMergeDocs>2147483647</maxMergeDocs> 
    <maxFieldLength>20000</maxFieldLength> 
    <writeLockTimeout>1000</writeLockTimeout> 
    <commitLockTimeout>10000</commitLockTimeout> 
    <!-- 
    Expert: 
    The Merge Policy in Lucene controls how merging is handled by Lucene. The default in 2.3 is the LogByteSizeMergePolicy, previous 
    versions used LogDocMergePolicy. 

    LogByteSizeMergePolicy chooses segments to merge based on their size. The Lucene 2.2 default, LogDocMergePolicy chose when 
    to merge based on number of documents 

    Other implementations of MergePolicy must have a no-argument constructor 
    --> 
    <mergePolicy>org.apache.lucene.index.LogByteSizeMergePolicy</mergePolicy> 
... 

Answer 2

Er Jungs,

Ich habe die MergePolicy zu LogByteSizeMergePolicy und MergeScheduler zu ConcurrentMergeScheduler geändert, die te Problem zu lösen scheint. Immer noch nicht ganz sicher, was passiert ist, aber wir sind wieder am Laufen;)

Danke!