Solr verwendet zu viel Speicher

9

Wir haben eine Solr 3.4-Instanz unter Windows 2008 R2 mit Oracle Java 6 Hotspot JDK, die nicht mehr reagiert. Als wir uns die Maschine ansahen, bemerkten wir, dass der verfügbare physische Speicher auf Null ging.

Der Tomcat7.exe-Prozess verwendete ~ 70Gigs (Privater Arbeitssatz), aber der Arbeitssatz (Speicher) verwendete den gesamten Speicher des Systems. Es gab keine Fehler in den Tomcat / Solr-Protokollen. Wir haben mit VMMap festgestellt, dass der Speicher für die Speicherzuordnung der Solr-Segement-Dateien verwendet wurde.

Ein Neustart von Tomcat hat das Problem vorübergehend behoben, aber es kam irgendwann zurück.

Wir haben dann versucht, die JVM-Größe zu verringern, um mehr Speicherplatz für die Speicherabbilddateien zu geben, aber dann reagiert der Solr schließlich mit der alten Generation bei 100% nicht mehr. Erneutes Zurücksetzen behebt das Problem, aber vor dem Zurücksetzen hat es keine Ausnahmebedingung ausgelöst.

Momentan sagt uns unser spitzköpfiger Sinn, dass der Cache bei Speicherdruck nicht schrumpft, und dass möglicherweise zu viele MappedByteBuffers herumliegen, so dass das Betriebssystem den Speicher nicht aus Speicherabbilddateien freigeben kann.

    
rjdevereux 27.03.2012, 17:36
quelle

2 Antworten

1

Es gibt zu viele Parameter und zu wenig Informationen, um bei Details zu helfen. Diese Antwort ist ebenso alt wie die erwähnten Systeme.

Hier sind einige Dinge, die in meiner Erfahrung geholfen haben:

  • Verringern Sie die RAM-Nutzung sowohl in Tomcat als auch in SOLR, um das Risiko des Tauschens zu verringern. Lassen Sie den Systemraum zum Atmen.
  • wenn dies "gestartet" wird, ohne Änderungen an Tomcat oder der SOLR-Konfiguration vorzunehmen - vielleicht liegt es daran, dass die Menge an Daten, die SOLR indexieren und abfragen muss, gestiegen ist. Dies kann entweder bedeuten, dass die ursprüngliche Konfiguration nie gut war oder dass das Limit der aktuellen Ressourcen erreicht wurde und überprüft werden muss. Welcher ist es?
  • check die Abfragen (wenn Sie sie beeinflussen können): Verschieben Sie alle Unterabfragekonstrukte, die oft in filterqueries angefordert werden, sehr individuelle Anfragekonstrukte in den regulären Abfrageparameter. Abfragecache verringern, Filterabfragecache erhöhen / beibehalten - oder Filtercache verringern, falls Filterabfragen in Ihrem System nicht so häufig verwendet werden.
  • Überprüfen Sie die schema.xml von SOLR auf Konfigurationsfehler (könnte wirklich Missverständnisse sein). Ich bin einmal auf dieses Problem gestoßen: Beim Importieren wurden Felder in Massen erstellt, die den RAM überlaufen ließen.
  • wenn es während des Imports passiert: Überprüfen Sie, ob der Importprozess auf Autocommit gesetzt ist und ob er häufig commit und auch optimiert - vielleicht ist es möglich, weniger oft zu committen und am Ende nur einmal zu optimieren.
  • Upgrade von Java, Tomcat und SOLR
Risadinha 15.04.2014 14:26
quelle
0

Das liegt wahrscheinlich an der neuen Standard-Richtlinie, die SOLR für Verzeichnisse verwendet (es versucht, sie dem RAM oder etwas Ähnlichem zuzuordnen).

Lesen Sie dies:
Ссылка

    
Fermin Silva 06.04.2012 18:10
quelle

Tags und Links

Django: Verwenden von Annotate, Count und Distinct in einem Queryset OpenID-Authentifizierung mit zufällig fehlgeschlagenem Google