Die Richtlinie für die Erkennung von Speicherlecks für WebSphere® Application Server ist standardmäßig inaktiviert. Sie können eine speziell auf Ihre Anwendungen und Ihre Umgebung abgestimmte Richtlinie für die Erkennung, Verhinderung und Behandlung von Speicherlecks konfigurieren, sodass potenzielle Speicherlecks gemeldet und bearbeitet werden. Die Erkennung, die Verhinderung und die proaktive Korrektur von Speicherlecks bieten Servern, auf denen permanente Fehler aufgrund abnormaler Speicherbedingungen auftreten, Schutz und Ausfallsicherheit. Wenn ein Speicherleck in einem Klassenlader festgestellt wird, werden Sie von WebSphere Application Server durch Informationsnachrichten im Protokoll und durch die Ausführung von JVM-Heapspeicherauszügen benachrichtigt, sodass Sie den Fehler beheben können. Außerdem können Sie wahlweise angeben, dass WebSphere Application Server das Speicherleck mithilfe von Reflexion und anderen Verfahren mindert und, falls möglich, beseitigt.
Vorbereitende Schritte
Ein verbreiteter Fehler in Java™ EE-Anwendungen (Java Platform, Enterprise Edition) ist ein Speicherleck in einem Klassenlader. Ein Speicherleck kann durch geringfügige Anwendungsfehler oder durch eine komplexere Verwendung (z. B. Bibliotheken anderer Anbieter) verursacht werden. Wenn ein Speicherleck besteht, werden Systemressourcen, z. B. CPU-Zeit aufgrund von Garbage-Collection und der Java-Heapspeicher, verbraucht. Ein System kann blockieren, obwohl alle anderen Ressourcen verfügbar sind. Falls kein Schutz- und Frühwarnsystem integriert ist, könnte das System in diesem verschlechterten Zustand bleiben und schließlich wegen eines Fehlers aufgrund abnormaler Speicherbedingungen ganz ausfallen.
Anmerkung: Mithilfe der Richtlinie für die Erkennung von Speicherlecks können Sie in WebSphere Application Server die Erkennung, die Verhinderung und, falls möglich, die Behandlung von Speicherlecks in einem Klassenlader konfigurieren. Weitere Informationen zu Speicherlecks finden Sie im Abschnitt zu Speicherlecks in Java EE-Anwendungen.
Informationen zu diesem Vorgang
Die Option für die Erkennung von Speicherlecks ist standardmäßig inaktiviert.
Sie können die Werte der Richtlinie für Speicherlecks mithilfe von angepassten JVM-Eigenschaften (Java Virtual Machine) ändern, z. B. die Erkennung, Behandlung und Verhinderung von Speicherlecks aktivieren und inaktivieren. Diese angepassten Eigenschaften sind nur für einen eigenständigen Server oder einen verwalteten Anwendungsserver gültig und nicht für einen Node Agent, Verwaltungsagenten, Job-Manager oder Deployment Manager. Wenn die Anwendung oder der Server beendet wird, ermittelt WebSphere Application Server die Klassenlader, bei denen ein Speicherleck aufgetreten ist, und die gesperrte Verweise für alle zugeordneten geladenen Klassen und Objekte sind. Wenn ein Speicherleck eines Klassenladers festgestellt wird, wird ein Heapspeicher- oder Systemspeicherauszug erstellt.
Alle persistenten Konfigurationen dieses Service werden mit angepassten JVM-Eigenschaften ausgeführt. Es gibt keine Administrationskonsolanzeigen. Verwenden Sie während der Ausführung die MBeans MemoryLeakConfig und MemoryLeakAdmin für die Konfiguration bzw. Verwaltung. Die Konfigurationsänderungen bleiben jedoch nicht bis zur Konfiguration von angepassten JVM-Eigenschaften bestehen.
Der Service für die Erkennung von Speicherlecks und seine MBean sind nur auf einem Anwendungsserver aktiv, auf dem sich Anwendungen und Serviceanforderungen befinden. Dieser Service ist auf einem Deployment Manager, Node Agent, Verwaltungsagenten oder anderen Servertypen wie WebSphere-Proxy-Server usw. nicht aktiv.
Tipp: Legen Sie in der Konfiguration der angepassten JVM-Eigenschaft com.ibm.ws.runtime.component.disableMemoryLeakService fest, dass der Service permanent inaktiviert wird.
Vorgehensweise
- Erstellen oder ändern Sie angepasste JVM-Eigenschaften, um verschiedene Aspekte des Service für die Erkennung von Speicherlecks zu aktivieren. Verwenden Sie hierfür die folgende Tabelle. Lesen Sie den Abschnitt Angepasste Eigenschaften der Java Virtual Machine, um Informationen zur Änderung der Werte der angepassten JVM-Eigenschaften zu erhalten.
Tabelle 1. com.ibm.ws.runtime.component.MemoryLeakConfig.detectAppCLLeaksInformation |
Wert |
Name |
com.ibm.ws.runtime.component.MemoryLeakConfig.detectAppCLLeaks |
Beschreibung |
Wenn der Server heruntergefahren wird oder eine Anwendung stoppt, ermittelt WebSphere Application Server die Klassenlader, bei denen ein Speicherleck aufgetreten ist, und gibt Warnungen oder andere zusätzliche Informationen aus, die bei der Behebung des Speicherlecks hilfreich sind. Siehe auch PMR (Problem Management Record) Improved classloader leak detection. |
Standard |
false |
Tabelle 2. com.ibm.ws.runtime.component.MemoryLeakConfig.clearAppCLLeaksInformation |
Wert |
Name |
com.ibm.ws.runtime.component.MemoryLeakConfig.clearAppCLLeaks |
Beschreibung |
Proaktive Mediation und Korrektur für Speicherlecks eines Klassenladers. Wenn diese Eigenschaft auf "true" gesetzt wird, vermittelt WebSphere Application Server im Namen der Anwendung, um alle festgestellten Speicherlecks von Klassenladern zu beheben. |
Standard |
false |
Tabelle 3. com.ibm.ws.runtime.component.MemoryLeakConfig.preventJreMemoryLeaksInformation |
Wert |
Name |
com.ibm.ws.runtime.component.MemoryLeakConfig.preventJreMemoryLeaks |
Beschreibung |
Ermöglicht WebSphere Application Server, bestimmte Klassen von Speicherlecks zu beseitigen, die durch die JRE-Ladesingletons im Threadkontextklassenlader verursacht werden. |
Standard |
true |
Tabelle 4. com.ibm.ws.runtime.component.MemoryLeakConfig.generateHeapDumpsInformation |
Wert |
Name |
com.ibm.ws.runtime.component.MemoryLeakConfig.generateHeapDumps |
Beschreibung |
Setzen Sie die Eigenschaft auf "true", damit ein Heapspeicherauszug erstellt wird, wenn ein Speicherleck festgestellt wird. |
Standard |
true |
Tabelle 5. com.ibm.ws.runtime.component.MemoryLeakConfig.leakSweeperDelayInformation |
Wert |
Name |
com.ibm.ws.runtime.component.MemoryLeakConfig.leakSweeperDelay |
Beschreibung |
Verzögerung nach dem Stoppen einer Anwendung oder eines Moduls, um auf Speicherlecks von Klassenladern zu prüfen. |
Standard |
10000 (Millisekunden) |
Tabelle 6. com.ibm.ws.runtime.component.MemoryLeakConfig.monitorSystemAppsInformation |
Wert |
Name |
com.ibm.ws.runtime.component.MemoryLeakConfig.monitorSystemApps |
Beschreibung |
Setzen Sie die Eigenschaft auf "true", um auf Speicherlecks in Systemanwendungen zu prüfen, die von IBM® bereitgestellt werden, z. B. der Administrationskonsole. |
Standard |
false |
Achtung: Sie können das Verhalten der Aktionsrichtlinie für Speicherlecks mithilfe der folgenden angepassten JVM-Eigenschaften für Thread- und
Zeitgeberlecks optimieren. Die angepassten Eigenschaften für Speicherlecks ThreadLocal, thread, timer und static sind nur gültig, wenn com.ibm.ws.runtime.component.MemoryLeakConfig.clearAppCLLeaks auf "true" gesetzt ist.
Tabelle 7. com.ibm.ws.runtime.component.MemoryLeakConfig.clearReferencesInterruptThreads . Thread- und ZeitgeberlecksInformation |
Wert |
Name |
com.ibm.ws.runtime.component.MemoryLeakConfig.clearReferencesInterruptThreads |
Beschreibung |
Setzen Sie die Eigenschaft auf "true", damit WebSphere Application Server versucht, Threads zu unterbrechen, die von der Webanwendung gestartet werden. Die Unterbrechung von Threads wird mit der Methode Thread.interrupt() ausgeführt. Es ist möglich, dass der Zielthread auf die Unterbrechung nicht reagiert. |
Standard |
true |
Tabelle 8. com.ibm.ws.runtime.component.MemoryLeakConfig.clearReferencesHttpClientKeepAliveThread . Thread- und ZeitgeberlecksInformation |
Wert |
Name |
com.ibm.ws.runtime.component.MemoryLeakConfig.clearReferencesHttpClientKeepAliveThread |
Beschreibung |
Wenn ein HttpClient-Keepalive-Zeitgeberthread nicht von dieser Webanwendung gestartet wird und immer noch aktiv ist, ändert WebSphere Application Server den Kontextklassenladers vom aktuellen Klassenlader in den zugehörigen übergeordneten Klassenlader, um ein Speicherleck zu verhindern. Der Keepalive-Zeitgeberthread stoppt von allein, wenn alle Keepalive-Threads beendet sind. In einem ausgelasteten System könnte das jedoch einige Zeit dauern. |
Standard |
true |
Tabelle 9. com.ibm.ws.runtime.component.MemoryLeakConfig.clearReferencesStopTimerThreads . Thread- und ZeitgeberlecksInformation |
Wert |
Name |
com.ibm.ws.runtime.component.MemoryLeakConfig.clearReferencesStopTimerThreads |
Beschreibung |
Setzen Sie die Eigenschaft auf "true", damit WebSphere Application Server alle java.util.TimerThreads stoppt, die von der Webanwendung gestartet werden. |
Standard |
false |
Tabelle 10. com.ibm.ws.runtime.component.MemoryLeakConfig.jvmThreadGroupNames. Thread- und ZeitgeberlecksInformation |
Wert |
Name |
com.ibm.ws.runtime.component.MemoryLeakConfig.jvmThreadGroupNames |
Beschreibung |
Liste der bei der Suche nach Threads, die von der zu beendenden Webanwendung gestartet werden, zu ignorierenden Threadgruppennamen. In dieser Liste werden Unterstreichungszeichen als Trennzeichen verwendet. |
Standard |
system__RMI Runtime |
Achtung: Die folgenden Eigenschaften für Lecks bei Variablen für statische Klassen sind nur gültig, wenn com.ibm.ws.runtime.component.MemoryLeakConfig.clearAppCLLeaks auf "true" gesetzt ist.
Tabelle 11. com.ibm.ws.runtime.component.MemoryLeakConfig.clearReferencesStatic. Lecks bei Variablen für statische KlassenInformation |
Wert |
Name |
com.ibm.ws.runtime.component.MemoryLeakConfig.clearReferencesStatic |
Beschreibung |
Setzen Sie die Eigenschaft auf "true",
damit WebSphere Application Server versucht,
alle Felder oder Endfelder in geladenen Klassen auf null zu setzen, wenn eine Webanwendung stoppt.
Dient als Problemumgehung für Garbage-Collection- und Anwendungscodefehler. Anwendungen ohne Speicherlecks, die aktuelle JVMs verwenden, sollten ordnungsgemäß ausgeführt werden, wenn diese Option auf "false" gesetzt wird. |
Standard |
false |
Tabelle 12. com.ibm.ws.runtime.component.MemoryLeakConfig.filterPrefixes. Lecks bei Variablen für statische KlassenInformation |
Wert |
Name |
com.ibm.ws.runtime.component.MemoryLeakConfig.filterPrefixes |
Beschreibung |
Mitgliedsattribute, die mit diesen Filtern beginnen, werden nicht auf null gesetzt, wenn clearReferencesStatic "true" ist. |
Standard |
java javax com.ibm org sun com.sun. In dieser Liste werden Leerzeichen als Trennzeichen verwendet. |
Achtung: Die folgenden Eigenschaften für Threadlocal-Lecks sind nur gültig, wenn com.ibm.ws.runtime.component.MemoryLeakConfig.clearAppCLLeaks auf "true" gesetzt ist.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
Tabelle 13. com.ibm.ws.runtime.component.MemoryLeakConfig.checkThreadLocalLeaks. Threadlocal-LecksInformation |
Wert |
Name |
com.ibm.ws.runtime.component.MemoryLeakConfig.checkThreadLocalLeaks |
Beschreibung |
Legt fest, ob ThreadLocal-Lecks überprüft werden sollen, wenn eine Anwendung stoppt. |
Standard |
false |
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
Tabelle 14. com.ibm.ws.runtime.component.MemoryLeakConfig.clearReferencesThreadLocal . Threadlocal-LecksInformation |
Wert |
Name |
com.ibm.ws.runtime.component.MemoryLeakConfig.clearReferencesThreadLocal |
Beschreibung |
Threadlocal-Lecks durch Erneuerung von Threads im Thread-Pool beim Stoppen einer Anwendung beseitigen. Diese Eigenschaft gilt nur für verteilte Plattformen. |
Standard |
true |
Achtung: Die folgenden Eigenschaften sind nur gültig, wenn clearReferencesThreadLocal auf "true" gesetzt ist.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
Tabelle 15. com.ibm.ws.runtime.component.MemoryLeakConfig.renewThreadPoolNames . Threadlocal-LecksInformation |
Wert |
Name |
com.ibm.ws.runtime.component.MemoryLeakConfig.renewThreadPoolNames |
Beschreibung |
Namen von Thread-Pools, die WebSphere Application Server erneuern muss, wenn ein Threadlocal-Leck festgestellt wird. |
Standard |
In der "WebContainer"-Liste werden Leerzeichen als Trennzeichen verwendet. |
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
Tabelle 16. com.ibm.ws.runtime.component.MemoryLeakConfig.threadPoolRenewalDelayFactor . Threadlocal-LecksInformation |
Wert |
Name |
com.ibm.ws.runtime.component.MemoryLeakConfig.threadPoolRenewalDelayFactor |
Beschreibung |
Die Gesamtwartezeit für die Erneuerung des Thread-Pools steuern. Wartezeit für die Erneuerung des Thread-Pools = threadPoolRenewalDelayFactor * threadPool.getKeepAliveTime() |
Standard |
10. Für den Web-Container-Thread-Pool beträgt die Erneuerungsverzögerung (10 * 60000 ms) 6 Minuten. |
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
Tabelle 17. com.ibm.ws.util.ThreadPool.DEFAULT_THREAD_RENEWAL_DELAY. Threadlocal-LecksInformation |
Wert |
Name |
com.ibm.ws.util.ThreadPool.DEFAULT_THREAD_RENEWAL_DELAY |
Beschreibung |
Threads im Pool werden nach dem Stoppen einer Anwendung erneuert. Mit dieser angepassten Eigenschaft können Sie vermeiden, dass alle Threads gleichzeitig erneuert werden. Diese Verzögerung tritt zwischen zwei Threads auf, die erneuert werden. |
Standard |
1000 (Wert in ms). Wenn der Wert negativ ist, werden Threads nie erneuert. |
Diese angepassten JVM-Eigenschaften werden im Konfigurationsmodell für WebSphere Application Server in der Datei
server.xml gespeichert. Das folgende Codefragment zeigt die gespeicherte Richtlinienkonfiguration für Speicherlecks aus der Datei
Serverausgangsverzeichnis/config/cells/nodes/servers/server.xml eines nicht verwalteten Servers:
<jvmEntries xmi:id="JavaVirtualMachine_1183122130078" verboseModeClass="true" verboseModeGarbageCollection="true" verboseModeJNI="false"
runHProf="false" hprofArguments="" debugMode="false" debugArgs="-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=7777"
genericJvmArguments="-agentlib:getClasses -Xquickstart -Xalwaysclassgc" executableJarFileName="" disableJIT="false">
<systemProperties xmi:id="Property_1317048628648" name="com.ibm.ws.runtime.component.MemoryLeakConfig.detectAppCLLeaks" value="true" />
<systemProperties xmi:id="Property_1318975518491" name="com.ibm.ws.runtime.component.MemoryLeakConfig.clearAppCLLeaks" value="true" />
<systemProperties xmi:id="Property_1318955284241" name="com.ibm.ws.runtime.component.MemoryLeakConfig.generateSystemDumps" value="false" />
<systemProperties xmi:id="Property_1319119976147" name="com.ibm.ws.runtime.component.MemoryLeakConfig.generateHeapDumps" value="true" />
<systemProperties xmi:id="Property_1317048628649" name="com.ibm.ws.runtime.component.MemoryLeakConfig.monitorSystemApps" value="false" />
</jvmEntries>
- Klicken Sie auf Anwenden.
- Klicken Sie auf OK.
- Speichern Sie die Änderungen. Führen Sie vor dem Neustart der Server unbedingt eine Dateisynchronisation durch.
- Starten Sie den Application Server neu, damit die Änderungen in Kraft treten.
Beispiel
Die Speicherleckrichtlinie für WebSphere Application Server kann mithilfe von angepassten JVM-Eigenschaften wie in diesem Beispiel beschrieben konfiguriert und gespeichert werden. Während der Ausführung kann die Konfiguration der Richtlinie für die Erkennung, Verhinderung und Behandlung von Speicherlecks mit der MBean MemoryLeakConfig geändert werden.
Die Verwaltung der Speicherleckrichtlinie kann mit der MBean MemoryLeakAdmin ausgeführt werden. Die Speicherleckrichtlinie hat Einfluss auf die Reaktion des Anwendungsservers auf ein Speicherleck in einem Klassenlader, wenn eine Anwendung oder der Server gestoppt wird.
Sie können die Einstellungen der Speicherleckrichtlinie mit der Scripting-Schnittstelle wsadmin anpassen. Diese Änderungen werden sofort wirksam,
werden jedoch in der Serverkonfiguration nicht persistent gespeichert und gehen beim
Neustart des Servers verloren. Das folgende Beispielscript zeigt, wie die Speicherleckrichtlinie mithilfe von wsadmin-Jacl-Scripting konfiguriert und verwaltet wird:
# Scripting in JACL
# Den Objektnamen des Speicherleckkonfigurationsobjekts abrufen, dessen Werte geändert werden sollen
set leakConfig [$AdminControl completeObjectName "type=MemoryLeakConfig,*"]
WebSphere:cell=smitaNode03Cell,name=LeakConfig,type=MemoryLeakConfig,node=smitaNode03,process=server1
# Den Objektnamen des Speicherleckverwaltungsobjekts abrufen, für das Operationen ausgeführt werden sollen
set leakAdmin [$AdminControl completeObjectName "type=MemoryLeakAdmin,*"]
WebSphere:cell=smitaNode03Cell,name=LeakAdmin,type=MemoryLeakAdmin,node=smitaNode03,process=server1
# Alle Attribute der MBean MemoryLeakConfig anzeigen
wsadmin>$Help all $leakConfig
Name: WebSphere:cell=smitaNode03Cell,name=LeakConfig,type=MemoryLeakConfig,node=smitaNode03,process=server1
Beschreibung: Informationen zur Managementschnittstelle der MBean
Klassenname: com.ibm.ws.runtime.component.MemoryLeakConfig
Attribut Typ Zugriff
JvmThreadGroupNames java.lang.String RW
FilterPrefixes java.lang.String RW
RenewThreadPoolNames java.lang.String RW
DetectAppCLLeaks boolean RW
ClearAppCLLeaks boolean RW
MonitorSystemApps boolean RW
NoDumps boolean RW
GenerateHeapDumps boolean RW
GenerateSystemDumps boolean RW
ClearReferencesStatic boolean RW
ClearReferencesInterruptThreads boolean RW
ClearReferencesStopTimerThreads boolean RW
ClearReferencesHttpClientKeepAliveThread boolean RW
ClearReferencesThreadLocal boolean RW
LeakSweeperDelay int RW
ThreadPoolRenewalDelayFactor int RW
PreventJreMemoryLeaks boolean RW
LeakConfiguration java.lang.String RO
Operation
Notifications
Constructors
# Die aktuelle Richtlinienkonfiguration für Speicherlecks an der Konsole ausgeben
wsadmin>$AdminControl getAttribute $leakConfig LeakConfiguration
MemoryLeakConfig [getClass()=class com.ibm.ws.runtime.component.MemoryLeakConfig, hashCode()=37266644
preventJreMemoryLeaks true
detectAppCLLeaks true
monitorSystemApps false
leakSweeperDelay 10000
clearAppCLLeaks true
clearReferencesStopTimerThreads false
clearReferencesHttpClientKeepAliveThread true
clearReferencesInterruptThreads true
jvmThreadGroupNames [system, RMI Runtime]
clearReferencesStatic true
filterPrefixes [java., javax., com.ibm., org., sun., com.sun]
clearReferencesThreadLocal true
renewThreadPoolNames [WebContainer]
threadPoolRenewalDelayFactor 1
noDumps false
generateHeapDumps true
generateSystemDumps false
# Konfiguration ändern
wsadmin>$AdminControl setAttribute $leakConfig ThreadPoolRenewalDelayFactor 10
wsadmin>$AdminControl setAttribute $leakConfig ClearReferencesStopTimerThreads true
# Aktualisierte Konfiguration anzeigen
wsadmin>$AdminControl getAttribute $leakConfig LeakConfiguration
MemoryLeakConfig [getClass()=class com.ibm.ws.runtime.component.MemoryLeakConfig, hashCode()=37266644
preventJreMemoryLeaks true
detectAppCLLeaks true
monitorSystemApps false
leakSweeperDelay 10000
clearAppCLLeaks true
clearReferencesStopTimerThreads true
clearReferencesHttpClientKeepAliveThread true
clearReferencesInterruptThreads true
jvmThreadGroupNames [system, RMI Runtime]
clearReferencesStatic true
filterPrefixes [java., javax., com.ibm., org., sun., com.sun]
clearReferencesThreadLocal true
renewThreadPoolNames [WebContainer]
threadPoolRenewalDelayFactor 10
noDumps false
generateHeapDumps true
generateSystemDumps false
# Alle Operationen der MBean MemoryLeakAdmin anzeigen
wsadmin>$Help all $leakAdmin
Name: WebSphere:cell=smitaNode03Cell,name=LeakAdmin,type=MemoryLeakAdmin,node=smitaNode03,process=server1
Beschreibung: Informationen zur Managementschnittstelle der MBean
Klassenname: com.ibm.ws.runtime.component.MemoryLeakAdmin
Operation
java.lang.String findLeaks()
java.lang.String fixLeaks()
java.lang.String fixLeaks(java.lang.String)
# Aktuelle Speicherlecks in einem Klassenlader suchen
wsadmin>$AdminControl invoke $leakAdmin findLeaks
CWMML0028I: Die folgenden Webanwendungen wurden gestoppt (erneut geladen, deimplementiert), aber ihre Klassen aus vorherigen Ausführungen sind weiterhin im Hauptspeicher geladen, was zu einem Speicherverlust führt.[[78577.075.724.NWALogging#NWALoggingEJB.jar]].
# Alle aktuellen Speicherlecks in einem Klassenlader beheben
wsadmin>$AdminControl invoke $leakAdmin fixLeaks
CWMML0036I: Suchen Sie im SystemOut-Protokoll nach den Ergebnissen der Operation zur Behebung von Speicherverlusten.
wsadmin>$AdminControl invoke $leakAdmin fixLeaks {"78577.075.724.NWALogging#NWALoggingEJB.jar"}
CWMML0036I: Suchen Sie im SystemOut-Protokoll nach den Ergebnissen der Operation zur Behebung von Speicherverlusten.