Behandlung von Fehlern
Java Abstürze
Manchmal kommen Fehler vor, die die Java-VM nicht mehr “sanft” behandeln kann. Dann beendet sich die VM und legt einen Crash-Report an. Häufig sind native Bibliotheken wie z. B. die FACT-Finder-Bibliothek dafür die Ursache.
Mit dem Java-Parameter -XX:ErrorFile= können Sie definieren, wo dieses Logfile hingeschrieben wird (vgl. Einrichten von Java).
OutOfMemory-Killer
Der OOM-Killer ist ein Kernel-Feature, mit dem das Betriebssystem gewaltsam sicherzustellen versucht, dass von den Anwendungen nicht mehr Speicher verwendet wird, als verfügbar. Wenn also FACT-Finder (und damit für das Betriebssystem Java) zu viel Speicher zu allozieren versucht, dann wird das Betriebssystem den Prozess beenden. Normalerweise wird FACT-Finder dann vom checkserver-Skript (siehe Nützliche Skripte) neu gestartet und das Problem ist beseitigt.
Es kommt aber insbesondere unter Linux auch vor, dass FACT-Finder so viel Speicher alloziert hat, dass gerade noch etwas freier Speicher übrig ist, und dann andere, Systemrelevante Prozesse nochmal ein Stückchen Speicher haben wollen, z. B. cron oder syslog. In diesem Fall werden diese Prozesse von Betriebssystem beendet. Wenn wir uns also vorstellen, dass Java noch mal Speicher bekam und diesen nicht mehr freigeben wird, danach cron möchte und dafür beendet wird, ist sichergestellt, dass checkserver.sh bei einem Absturz nicht neu gestartet wird. Wenn also checkserver.sh nun (warum auch immer) noch ein Stück Speicher beim Kernel anfragt, wird er beendet und die nächste Anfrage für Speicher von Java ist abzusehen und damit das Ende des Dienstes von FACT-Finder. Es lohnt sich also, auch den Füllstand des Speichers aus Betriebssystem-Sicht zu überwachen.
Der OOM-Killer logt ins Syslog. Wenn also Prozesse fehlen, die man auf einem Server erwartet, so sollte man im Syslog nach dem OOM-Killer suchen.
Tomcat
Bei einem nicht mehr funktionierenden Tomcat-Server empfiehlt sich insbesondere das Studium der catalina.out-Logdatei. Oftmals wird man dort die Erklärung für die Ausnahme finden.
Häufig wiederkehrende Probleme sind:
| Fehlermeldung | Erklärung |
|---|---|
java.lang.OutOfMemoryError: Java Heap | siehe Software Einrichtung. Hier ist vermutlich der Wert für Xms und Xmx nicht optimal gesetzt. |
java.lang.OutOfMemoryError: PermGen space | In alten FACT-Finder Versionen, die noch Java 7 verwendet haben, tratt dieser Fehler auf wenn sich die Werte für den Java Heap und Permgen in die Quere gekommen sind. Ab FACT-Finder 7.0 sollte dieser Fehler nicht mehr auftreten, da Java 8 keine Unterscheidung zwischen beiden trifft. |
de.factfinder.jni.FactFinderException: Out of memory! | Diese Meldung stammt aus der FACT-Finder Bibliothek, wenn diese zu wenig Speicher zur Verfügung hat. Die Java-VM und die FACT-Finder Bibliothek laufen im selben Prozess, teilen sich aber nicht denselben Speicher. Der Speicher, der Java zugesichert wird, steht nicht der Bibliothek zur Verfügung. Beispiel Wenn Java auf einem 4 GB System 3,5 GB zugewiesen bekommt, dann bleiben der FACT-Finder Library die restlichen 500 MB übrig. |
All Threads (150) busy | Diese Meldung bedeutet grundsätzlich, dass der Server nicht über genug CPU-Leistung verfügt. Wenn zusätzlich die CPU-Load aber nicht deutlich erhöht ist, kann das an einer schlechten Netzwerk-Verbindung zwischen FACT-Finder und dem Shop-System liegen. Konsultieren Sie im Zweifel den FACT-Finder-Support. |
BeforeAccessLogValve
Falls ein Fehler wiederholt auftritt, kann zur besseren Analyse ein weiterer LogValve konfiguriert werden, der Requests logt, wenn diese eintreffen, nicht erst, wenn sie verarbeitet wurden. So lassen sich manche Fehler besser finden, weil auch Requests erfasst werden, deren Abarbeitung nicht mehr geloggt würde. Dieser Valve sollte aber nur für Debugging-Zwecke eingesetzt werden und ist für den Normalbetrieb nicht empfohlen.
Eine Beispiel-Konfiguration sieht wie folgt aus und muss in die server.xml des Tomcats eingefügt werden:
<Valve className="org.apache.catalina.valves.BeforeAccessLogValve" directory="logs"
prefix="localhost_pre_access_log." suffix=".txt"
pattern="%h %t %S "%r" "%{Referer}i""
resolveHosts="false"
buffered="true"/>