Webmodul oder Anwendungsserver verarbeitet keine Anforderungen mehr
Wenn ein Anwendungsserverprozess plötzlich geschlossen wird oder seine Webmodule ganz plötzlich nicht mehr auf neue Anforderungen reagieren, ist es wichtig, dass Sie die Ursache dieses Problems schnell feststellen. Sie können einige der folgenden Verfahren einsetzen, um zu bestimmen, ob das Problem auf ein Webmodul oder eine Anwendungsserverumgebung zurückzuführen ist.
- Grenzen Sie das Problem ein, indem Sie, sofern möglich, Webmodule in anderen Servern installieren.
Überprüfen Sie die Produktverzeichnisstruktur auf eine Datei mit dem Namen javacore[Nummer].txt. Dieses Datei ist eine Java™-Datei mit einem Threadspeicherauszug, die die JVM erstellt, wenn ein Anwendungsserverprozess plötzlich geschlossen wird.
Wenn ein Anwendungsserverprozess plötzlich geschlossen wird, wird ein SDUMP erstellt, den Sie analysieren können.
- Mit dem Tivoli Performance Viewer
können Sie feststellen, ob die Anwendungsserverressourcen, z. B. der Java-Freispeicher oder die Datenbankverbindungen, ihre maximale Kapazität erreicht haben. Liegt ein Ressourcenproblem vor, so überprüfen Sie den Anwendungscode auf eine mögliche Ursache:
- Wenn Datenbankverbindungen einer Anforderung zugeordnet sind, jedoch nie freigegeben werden, vergewissern Sie sich, dass der Anwendungscode die Methode close() für ein geöffnetes Verbindungsobjekt in einem finally{}-Block ausführt.
- Wenn die Anzahl der Threads der Servlet-Maschine ständig zunimmt, überprüfen Sie die synchronisierten Codeblöcke auf mögliche Sperrbedingungen.
- Wenn die Größe eines JVM-Heapspeichers ständig zunimmt, überprüfen Sie den Anwendungscode auf mögliche Speicherverluste, wie z. B. statische Objektgruppen (Klassenebene), die bewirken, dass für Objekte nie eine Garbage-Collection durchgeführt wird.
- Aktivieren Sie die ausführliche Garbage-Collection für den Anwendungsserver, um festzustellen, ob ein Speicherverlust vorliegt. Diese Funktion fügt der JVM-Fehlerprotokolldatei detaillierte Angaben
zur Kapazität des verfügbaren und des benutzten Speichers hinzu. Gehen Sie zum Aktivieren der ausführlichen Ausgabe für die Garbage-Collection wie folgt vor:
Klicken Sie in der Administrationskonsole auf Servername. Klicken Sie anschließend unter "Serverinfrastruktur" auf und wählen Sie Ausführliche Garbage-Collection aus.
Klicken Sie in der Administrationskonsole auf Servername. Klicken Sie anschließend im Abschnitt "Serverinfrastruktur" auf und wählen Sie Ausführliche Garbage-Collection aus.
- Stoppen Sie den Anwendungsserver und starten Sie ihn dann erneut.
- Durchsuchen Sie die Protokolldatei in regelmäßigen Abständen nach Informationen zur Garbage-Collection. Suchen Sie nach Anweisungen, die mit "allocation failure" beginnen. Diese Zeichenfolge weist darauf hin, dass die JVM-Garbage-Collection ausgelöst wurde, weil Speicher zugeordnet werden muss. Bei der Garbage-Collection wird nicht benutzter Speicher freigegeben. Reservierungsfehler sind an sich normal und weisen nicht zwingend auf ein Problem hin. Der Anweisung "allocation failure" folgen Anweisungen, die die benötigten Bytes und die reservierten Bytes anzeigen. Wenn die Anweisungen zu den benötigten Bytes erkennen lassen, dass die JVM weiterhin mehr Speicher als benötigt für sich zuordnet, oder wenn die JVM nicht mehr in der Lage ist, soviel Speicher wie benötigt zuzuordnen, liegt möglicherweise ein Speicherverlust vor.
Sie können auch den Tivoli Performance Viewer verwenden, um Speicherverluste zu ermitteln.
Stellen Sie fest, ob die Speicherkapazität des Anwendungsservers erschöpft ist. Wenn Sie feststellen, dass dies der Fall ist, könnte einer der folgenden Fehler vorliegen:
- Im Anwendungscode ist ein Speicherverlust vorhanden, der untersucht
werden muss. Zur Ermittlung der Ursache des Speicherverlusts aktivieren Sie die Eigenschaft
RunHProf auf der Seite
"Java Virtual Machine" in der Administrationskonsole. Servername ist der Name des fehlerhaften Anwendungsservers. Nach der Aktivierung der
Eigenschaft RunHProf müssen Sie wie folgt vorgehen:
- Setzen Sie im Feld HProf-Argumente auf einen Wert wie depth=20,file=heapdmp.txt. Dieser Wert zeigt Ausnahme-Stacks mit einer maximalen Tiefe von 20 Ebenen an und speichert die Ausgabe von des Heapspeicherauszugs in der Datei Stammverzeichnis_des_Anwendungsservers/bin/heapdmp.txt.
- Speichern Sie die Einstellungen.
- Stoppen Sie den Anwendungsserver und starten Sie ihn dann erneut.
- Wiederholen Sie das Szenario, sofern möglich, oder greifen Sie auf die Ressource zu, die dafür verantwortlich war, dass der Anwendungsserverprozess plötzlich geschlossen wurde oder die Webmodule des Anwendungsserverprozesses keine neuen Anforderungen mehr verarbeitet haben. Stoppen Sie anschließend den Anwendungsserver. Falls Sie das Szenario nicht wiederholen oder nicht auf die Ressource zugreifen können, warten Sie, bis das Problem erneut auftritt, und stoppen Sie dann den Anwendungsserver.
- Prüfen Sie die Datei, in der der Heapspeicherauszug gespeichert wurde. Untersuchen Sie beispielsweise
die Datei Stammverzeichnis_des_Anwendungsservers/bin/heapdmp.txt:
- Suchen Sie nach der Zeichenfolge "SITES BEGIN". Auf diese Weise erhalten Sie eine Liste von Java-Objekten im Speicher, die Ihnen Aufschluss über den für die Objekte reservierten Speicher gibt.
- Die Liste der Java-Objekte wird bei jeder Speicherreservierung in der JVM erweitert. Sie enthält einen Datensatz mit dem Typ des Objekts, für das der Speicher instanziert wurde. Irgendwo im Speicherauszug ist eine ID eines Trace-Stack enthalten, die die Java-Methode angibt, die die Reservierung vorgenommen hat.
- Die Liste der Java-Objekte ist in absteigender Reihenfolge nach der Anzahl der reservierten Bytes sortiert. Je nach Art des Speicherverlusts wird die fehlerhafte Klasse nahe beim Anfang der Liste angezeigt, das ist jedoch nicht immer der Fall. Suchen Sie in der Liste nach großen Speicherkapazitäten oder wiederholten Instanzierungen derselben Klasse. Im letzeren Fall verwenden Sie die ID in der Spalte Trace-Stack, um Reservierungen zu ermitteln, die in derselben Klasse und Methode wiederholt durchgeführt werden.
- Überprüfen Sie den Quellcode, der in den zugehörigen Trace-Stacks angezeigt ist, auf mögliche Speicherverluste.
- Die JVM verwendet die maximale Freispeichergröße, die sie verwenden darf. In dieser Situation sollten Sie den Wert für die maximale Größe des Heapspeichers für den Anwendungsserver erhöhen, wenn genügend Speicherkapazität verfügbar ist.
- Es liegt ein Problem mit der Serverlaufzeit vor. Wenn Sie feststellen, das ein Problem mit der Serverlaufzeit vorliegt, vergewissern Sie sich, dass Sie alle Serviceaktualisierungen für das Produkt angewendet haben. Wenn das Problem, nachdem Sie alle Funktionsaktualisierungen durchgeführt haben, weiterhin auftritt, wenden Sie sich an die IBM® Unterstützungsfunktion.
- Im Anwendungscode ist ein Speicherverlust vorhanden, der untersucht
werden muss. Zur Ermittlung der Ursache des Speicherverlusts aktivieren Sie die Eigenschaft
RunHProf auf der Seite
"Java Virtual Machine" in der Administrationskonsole. Servername ist der Name des fehlerhaften Anwendungsservers. Nach der Aktivierung der
Eigenschaft RunHProf müssen Sie wie folgt vorgehen:
Durchsuchen Sie den Threadspeicherauszug nach Anhaltspunkten:
Wenn plötzlich ein Anwendungsserverprozess geschlossen wird, erstellt die JVM einen Threadspeicherauszug. Sie können auch eine Anwendung zwingen, einen Threadspeicherauszug zu erstellen. Nach der Erstellung eines Speicherauszugs können Sie diesen überprüfen, um festzustellen, ob er Hinweise auf die Frage enthält, warum neue Anforderungen nicht verarbeitet werden.
Generieren Sie den Threadspeicherauszug wie folgt:
- Fordern Sie mit dem Befehlszeilenprogramm wsadmin ein Handle
für den fehlerhaften Anwendungsserver an:
wsadmin>set jvm [$AdminControl completeObjectName type=JVM,process=Servername,*]
Servername steht für den Namen Ihres Servers.
- Generieren Sie den Threadspeicherauszug:
wsadmin>$AdminControl invoke $jvm dumpThreads
Anmerkung: Der Befehl "dumpThreads" erstellt basierend auf den -Xdumps-Einstellungenen andere Typen von Speicherauszugsdateien. Die Ausgabe des Speicherauszugs ist abhängig von der Plattform und kann Systemkerndateien, Heapspeicher und Kurzspeicherauszüge enthalten. Suchen Sie im Verzeichnis Profilstammverzeichnis/logs eine Ausgabedatei mit einem Namen wie javacore.Jobnummer.Jobbenutzer.Jobname.Zeitmarke.txt.
Suchen Sie im Installationsstammverzeichnis des Produkts nach einer Ausgabedatei mit dem Namen javacore.Datum.Zeit.ID.txt.
Nachdem die Anwendung den Speicherauszug erstellt hat, können Sie nach folgenden Hinweisen suchen:
Am Anfang der Datei sind möglicherweise Zeichenfolgen vom Typ "Error" oder "exception information" enthalten. Diese Zeichenfolgen geben den Thread an, der für das plötzliche Schließen des Anwendungsservers verantwortlich ist. Sie erscheinen nicht, wenn Sie den Speicherauszug erzwungen haben.
Prüfen Sie, ob die aktuelle Größe des Heapspeichers übermäßig hoch ist. Der Threadspeicherauszug enthält Informationen zur aktuellen Größe und zu den Mindest- und Maximaleinstellungen für die Größe des Java-Heapspeichers.
Sehen Sie sich die Momentaufnahmen der einzelnen Threads im Prozess an. Der Threadspeicherauszug enthält eine Momentaufnahme der einzelnen Threads im Prozess, die im Abschnitt mit der Kennzeichnung "Full thread dump" beginnt.
- Suchen Sie nach Threads mit einer Beschreibung, die "state:R" enthält. Solche Threads sind dann aktiv, wenn ein Speicherauszug angefordert oder ein Prozess beendet wurde.
- Suchen Sie nach mehreren Threads, in denen derselbe Java-Anwendungscode ausgeführt wird. Mehrere Threads mit derselben Position können auf eine gegenseitige Sperre (Deadlock) (mehrere Threads warten auf den Monitor) oder eine Endlosschleife hinweisen und helfen Ihnen, den Anwendungscode, der das Problem verursacht, zu identifizieren.
Sehen Sie sich die Momentaufnahmen der einzelnen Threads im Prozess an. Der Threadspeicherauszug enthält eine Momentaufnahme der einzelnen Threads im Prozess, die im Abschnitt mit der Kennzeichnung "Thread Information" beginnt.
- Suchen Sie nach Threads, die auf Sperren warten, die von anderen Threads gesetzt wurden.
- Suchen Sie nach mehreren Threads, in denen derselbe Java-Anwendungscode ausgeführt wird.
Mehrere Threads mit derselben Position können auf eine gegenseitige Sperre (Deadlock)
(mehrere Threads warten auf den Monitor) oder eine Endlosschleife hinweisen und helfen
Ihnen, den Anwendungscode, der das Problem verursacht, zu identifizieren.
Es ist nicht ungewöhnlich, dass bestimmte Komponenten in der Laufzeitumgebung des Produkts bestimmte Threadtypen an derselben Position im Java-Quellcode verwenden. Zu diesen Komponenten gehören der Web-Container, der EJB-Container und der ORB-Thread-Pool.
- Fordern Sie mit dem Befehlszeilenprogramm wsadmin ein Handle
für den fehlerhaften Anwendungsserver an: