2012-04-11 9 views
2

Wir haben vor kurzem von solr3.1 auf solr3.5 migriert, wir haben einen Master und einen Slave konfiguriert. Der Master hat zwei Kerne,Solr 3.5 Indexierung dauert sehr lange

1) Core1 – 44555972 documents 
2) Core2 – 29419244 documents 

Wir verpflichten alle 5000 Dokumente, aber in letzter Zeit die commit nehmen sehr lange 15 Minuten und in einigen Fällen. Was das verursacht haben könnte, habe ich die Protokolle überprüft und die einzige Warnung, die ich sehen kann, ist

"WARNUNG: Verwendung des veralteten Aktualisierungsanforderungsparameters update.processor erkannt. Bitte benutzen Sie den neuen Parameter update.chain stattdessen als Unterstützung für update.processor wird in einer späteren Version entfernt werden.“

Speicherdetails:

export JAVA_OPTS =" $ JAVA_OPTS -Xms6g -Xmx36g -XX: MaxPermSize = 5g“

Solr Config:

<useCompoundFile>false</useCompoundFile> 
<mergeFactor>10</mergeFactor> 
<ramBufferSizeMB>32</ramBufferSizeMB> 
<!-- <maxBufferedDocs>1000</maxBufferedDocs> --> 
<maxFieldLength>10000</maxFieldLength> 
<writeLockTimeout>1000</writeLockTimeout> 
<commitLockTimeout>10000</commitLockTimeout> 

bemerkt auch, dass t Op-Befehl zeigt fast 350 GB virtuellen Speicherverbrauch.

Was könnte das verursachen, da vor ein paar Tagen alles gut lief?

+0

Optimieren Sie bei jedem Commit? Und das ist eine sehr große Menge an Speicher für die JVM, betrachten Sie einen viel kleineren Haufen, vielleicht 4G oder 8G. Sie könnten Minuten in einem GC verbringen. –

+0

Nein, wir optimieren nicht jedes Commit, wir machen es einmal am Tag. – sesmic

Antwort

0

Haben Sie eine große Suchanfrage zum Aufwärmen? Unsere Commits dauern bis zu 2 Minuten, weil die Suche sich erwärmt hat. Frage mich, ob das der Fall ist.

Die große virtuelle Speicherbelegung würde dies erklären.