Software einrichten

Java

Notwendige Einstellungen

FACT-Finder benötigt zwei Umgebungsvariablen:

  • FACTFINDER_RESOURCES gibt an, in welchem Pfad die Anwendung einen anwendungsspezifischen Ordner findet bzw. anlegen kann um Anwendungsdaten (zB Konfigurationen, Exporte, Datenbanken) zu halten. Der Pfad kann beliebig gewählt werden, wir empfehlen /opt/factfinder zu wählen.
  • FACTFINDER_KEY gibt den Pfad zur Lizenzdatei an, die Sie von Omikron erhalten haben.

Die Variablen werden dem Tomcat am Besten über die setenv.sh übergeben, die in unserem Fall unter /usr/share/tomcat8/bin mit folgendem Inhalt angelegt werden muss:

export JAVA_OPTS="$JAVA_OPTS\
 -DFACTFINDER_RESOURCES=/opt/factfinder\
 -DFACTFINDER_KEY=/opt/factfinder/licence.ffkey"

Nach einem Neustart des Tomcats sollten die Variablen im Prozess erkennbar sein, was sich über den Befehl ps aux | grep FACTFINDER überprüfen lässt.

Empfohlene Einstellungen

Wir empfehlen, neben den FACT-Finder-spezifischen Umgebungsvariablen auch die Speicherzuweisungen für JAVA explizit zu setzen. Der initiale Heapspace wird mit dem Parameter -Xms, der maximale Heapspace mit -Xmx gesetzt. Die zu setzenden Werte orientieren sich an der Datenbankgröße von FACT-Finder und dem zur Verfügung stehenden Arbeitsspeicher. 

Generell sollte der Java-Heap so groß wie möglich gefasst werden. Das ermöglicht es speicherbasierten Caches sich auszudehnen und dadurch wichtige Performance-Vorteile zu erzielen. Der Java-Heap konkurriert allerdings mit dem Native-Heap. FACT-Finder Datenbanken werden nicht in den Java-Heap sondern in den Native-Heap geladen. Je größer der Java-Heap gewählt wird, desto weniger Platz steht dem Native-Heap zur Verfügung. Daher sollte bei der Wahl der Java-Heap-Größe immer genügend Speicher für den Native-Heap übrig gelassen werden.

Beispiel: Eine FACT-Finder-Instanz betreibt drei Channel. Die FACT-Finder-Produkt-Datenbanken der Channel haben die Größen 50MB, 70MB und 130MB. Für den dritten Channel wurde die Multi-Lib-Funktion aktiviert und die Anzahl der zu verwendenden Libs auf 4 gesetzt. Der grobe Speicherbedarf für den Native-Heap berechnet sich so:

((50 + 70 + 130 * 4) + (5 + 7 + 13) + 130) * 2 = 1590

Die ersten drei Zahlen sind die Größen der FACT-Finder-Produktdatenbanken. Die Multi-Lib-Funktion lädt die Datenbank mehrfach in den Speicher. Deshalb wird die Datenbank-Größe des Channels mit der Anzahl der konfigurierten Libs multipliziert. Die folgenden drei Zahlen sind die geschätzten Größen der Suggest-Datenbanken der Channel. Gerade bei großen Suggest-Datenbanken sollte man deren Einfluss nicht ignorieren. Der letzte Wert repräsentiert den Speicherbedarf des Produkt-Daten-Imports. Da der Import parallel zur Suche ausgeführt wird, muss auch zusätzlicher Speicher dafür reserviert werden. Es werden niemals mehrere Importe parallel ausgeführt. Daher ist es ausreichend für den Import Speicher für einen Channel zu reservieren. Es wird dafür die Größe des größten Channels genommen. Alle Datenbanken zusammen werden mal 2 genommen, da der Bedarf im RAM grob doppelt so groß ist wie auf der Platte.

Hinweis: Falls für die FACT-Finder-Instanz asynchrones Neuladen der Datenbanken aktiviert wurde (tableLoadAsync=true in fff.properties) wird zusätzlich für das Neuladen extra Speicher benötigt. Für das Laden wird so viel Speicher benötigt wie für das Halten der Datenbanken. Das bedeutet wenn für Channel 3 130 * 4 * 2 MB benötigt wird, dann wird genau so viel noch ein mal für das asynchrone Neuladen benötigt.

Beim Laden der Datenbanken ist die Situation der parallelen Verarbeitung komplizierter als beim Import. Es können theoretisch mehrere Datenbanken gleichzeitig geladen werden. Das würde bedeuten, dass man für diesen Fall noch mal so viel Speicher reserviert werden müsste wie für die schon geladenen Datenbanken. In der Praxis tritt dieser Fall allerdings nur in sehr speziellen Situationen ein. Ohne Eingriff von außen wird FACT-Finder Datenbanken immer hintereinander laden, niemals parallel. Falls allerdings die Datenbank-Reload-API gleichzeitig mehrfach von außen aufgerufen wird, und sich zudem die Datenbanken auf der Platte geändert haben, werden diese Datenbanken parallel geladen.

Hier Ergänzung der obigen Formel um den Speicherbedarf für asynchrones Laden (es wird angenommen, dass die Datenbanken niemals parallel neugeladen werden:

((50 + 70 + 130 * 4) + (5 + 7 + 13) + 130 + (130 * 4)) * 2 = 2630

Wenn Sie die empfohlene tcmalloc-Bibliothek installiert haben, aktivieren Sie deren Nutzung ebenfalls über die setenv.sh. Hierfür ist der zweite export-Befehl in der Datei zuständig.

Mit setzen der Werte, würde die setenv.sh beispielweise wie folgt aussetzen:

export JAVA_OPTS="$JAVA_OPTS\
 -DFACTFINDER_RESOURCES=/opt/factfinder\
 -DFACTFINDER_KEY=/opt/factfinder/licence.ffkey\
 -Xms512m\
 -Xmx3g"

export LD_PRELOAD=/usr/lib/libtcmalloc_minimal.so.4

Ab FACT-Finder 7.3.4-0 wird empfohlen den Xss auf 4m zu setzen

-Xss4m

Der Standardwert ist: Xss2m


Ob tcmalloc erfolgreich aktiviert wurde, kann nach einem Tomcatneustart über folgenden Befehl überprüft werden. Nach Eingabe von diesem, müssten Sie Einträge sehen.

sudo grep malloc /proc/[TOMCAT-PROCESS-ID]/maps

Optionale Einstellungen

Die zuvor genannten Java Optionen sind das, was FACT-Finder für den Betrieb benötigt bzw. wir empfehlen. Zusätzlich sind, aus unserer Sicht, weitere Einstellungen für den Java- bzw. Tomcatprozess ratsam. Diese sind aber nicht notwendig und eventuell gibt es zu den generellen Einstellungen je Firma andere Standardsets.

Die untere Datei wird von Omikron im FACT-Finder Betrieb verwendet. Neben generellen Einstellungen zu Tomcat und Java, sind foglende Parameter enthalten, die eine spezielle Bedeutung haben:

  • RECOVERY_SCRIPT und XX:OnOutOfMemoryError verweisen auf das Emergency-Skript von Omikron, so dass im Fehlerfall Daten zur späteren Analyse gesammelt wird. Eine detaillierte Erklärung hierzu findet sich im Kapitel "Nützliche Skripte". XX:OnOutOfMemoryError wird von Java bzw. Tomcat ausgeführt, wenn er den OutOfMemory-Fall bemerkt. Bei RECOVERY_SCRIPT handelt es sich eine FACT-Finder spezifische Variable, die definiert welches Skript ausgeführt wird, sollte das Programm selbst ein schwerwiegendes Problem erkennen und sich neustarten wollen.

  • productiveTomcat wird vom e.sh-Skript verwendet um den Tomcatprozess zu identifizieren, für den es die Daten sammeln und welchen es im Anschluss beenden soll.

  • Der Parameter instance wird auf einen Wert gesetzt, mit dem man das System bzw. die Suchanwendung identifiziert. Gerade bei Betriebsszenarien, die mehrere Suchanwendungen beinhalten ist dies zu empfehlen.

export JAVA_OPTS="$JAVA_OPTS\
 -DFACTFINDER_RESOURCES=/opt/factfinder\
 -DFACTFINDER_KEY=/opt/factfinder/licence.ffkey\
 -Xms512m\
 -Xmx3g\
 -DRECOVERY_SCRIPT=/opt/factfinder/e.sh\
 -XX:OnOutOfMemoryError=/opt/factfinder/e.sh\
 -DproductiveTomcat\
 -Dinstance='hostname'\
 -Djava.awt.headless=true\
 -Djava.security.egd=file:/dev/./urandom\
 -Dcom.sun.management.jmxremote\
 -verbose:gc\
 -XX:+PrintGCDetails\
 -XX:+PrintGCTimeStamps\
 -XX:+PrintGCDateStamps\
 -XX:+UseGCOverheadLimit\
 -XX:GCHeapFreeLimit=25\
 -XX:NewRatio=2\
 -XX:MaxMetaspaceSize=2g\
 -XX:ErrorFile=/opt/factfinder/dumps/hs_err_pid\$\$.log\
 -Xloggc:/opt/factfinder/dumps/gclog.'date +\%F_\%R'.txt\
 -Dorg.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER=true\
 -Dorg.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE=2000000\
 -Dderby.stream.error.file=/opt/factfinder/dumps/derby.\$\$.log"

export LD_PRELOAD=/usr/lib/libtcmalloc_minimal.so.4

Tomcat

Notwendige Einstellungen

Stellen Sie sicher, dass das Encoding des Tomcats auf UTF-8 steht. Welches Encoding eingestellt ist erkennen Sie am Attribut URIEncoding="UTF-8" innerhalb des Connector-Tags in der server.xml. In unserem Fall befindet sich diese Datei unter /var/lib/tomcat8/conf. Seit Tomcat 8 ist dies die Standardeinstellung, in früheren Versionen muss das URIEncoding-Attribut entsprechend hinzugefügt werden.

Folgendes Beispiel zeigt eine korrekte Connector-Konfiguration.

<Connector port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               URIEncoding="UTF-8"
               redirectPort="8443" />

Empfohlene Einstellungen

Mit einem Executor definiert man im Tomcat das Thread-Pooling. Als Wert für die Attribute minSpareThreads und maxThreads setzt man 4 * Anzahl-CPU-Kerne. Sie drücken aus, wie viele Threads maximal im Pool bzw. wie viele mindestens am Leben gehalten werden. Das Attribut prestartminSpareThreads sorgt lediglich dafür, dass die minSpareThreads beim Starten des Executors schon berücksichtigt werden. Über das name-Attribute bzw. das executor-Attribute im Connector werden beide miteinander verknüpft.

Zusätzlich empfehlen wir foglende weitere Connector-Einstellungen:

  • Änderung von protocol auf org.apache.coyote.http11.Http11NioProtocol, da dies ein Non-Blocking Java Connector ist.
  • Setzen von acceptCount auf einen relativ hohen Wert, dieser definiert wie viele Anfragen akzeptiert werden, wenn alle Tomcat-Threads gerade belegt sind.
  • Über die Attribute compression, compressableMimeType und compressionMinSize wird die GZIP-Datenkomprimierung bei der Rückgabe aktiviert. In manchen Fällen (z. B. in der Navigation) kann die Such-Rückgabe sehr groß werden, wodurch die Netzwerk-Laufzeit ein nicht unerheblicher Bestandteil der gesamten Suchzeit ist und dem somit entgegen gewirkt wird. compressableMimeType gibt an, welche Rückgaben komprimiert werden sollen, und compressionMinSize ab welcher Größe dies getan wird.

<Executor 
    name="tomcatThreadPool" maxThreads="32"
    minSpareThreads="32" prestartminSpareThreads="true"/>

<Connector port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol"
	connectionTimeout="20000"
	URIEncoding="UTF-8"
    redirectPort="8443"
	executor="tomcatThreadPool"    
    acceptCount="1000"
    compression="on"
    compressableMimeType="text/html,text/xml,text/plain,text/javascript,text/css,application/json"
    compressionMinSize="2048" />

Optionale Einstellungen

Unserer Erfahrung nach ist folgende Anpassung des AccessLogValve sinnvoll um mehr Informationen in den Zugriffslogfiles zu haben. Die Überwachungs-Skripte von Omikron setzen dieses Format voraus, möchten Sie diese nutzen, ist untere Konfiguration notwendig.

Die Abstände in den Werten im Attribut pattern sind Tabulatoren.

<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
	prefix="localhost_access_log." suffix=".txt"
	pattern="%h %t  %S  &quot;%r&quot; &quot;%{Referer}i&quot;  %s  %b  %D" 
    resolveHosts="false"
    buffered="true" />
Auf dieser Seite