Verwenden Sie diese Seite, um die JVM-Konfigurationseinstellungen (Java Virtual Machine) eines Prozesses für einen Anwendungsserver anzuzeigen und zu ändern.
Stellen Sie zum Anzeigen dieser Seite der Administrationskonsole eine Verbindung zur Administrationskonsole her, und navigieren Sie zur Anzeige "Java Virtual Machine".
Für i5/OS und verteilte Plattformen klicken Sie auf
Server > Servertypen > WebSphere-Anwendungsserver > Servername.
Klicken Sie anschließend im Abschnitt "Serverinfrastruktur" auf Java- und
Prozessverwaltung > Prozessdefinition > Java Virtual Machine
Anwendungsserver | Klicken Sie auf Server > Servertypen > WebSphere-Anwendungsserver > Servername.Klicken Sie anschließend im Abschnitt "Serverinfrastruktur" auf Java- und Prozessverwaltung > Prozessdefinition > Steuerung > Java Virtual Machine |
Deployment Manager | Klicken Sie auf Systemverwaltung > Deployment Manager. Klicken Sie anschließend im Abschnitt "Serverinfrastruktur" auf Java- und Prozessverwaltung > Prozessdefinition > Steuerung > Java Virtual Machine |
Node Agent | Klicken Sie auf Systemverwaltung > Node Agent > Node_Agent. Klicken Sie anschließend im Abschnitt "Serverinfrastruktur" auf Java- und Prozessverwaltung > Prozessdefinition > Java Virtual Machine |
Anwendungsserver | Klicken Sie auf Server > Servertypen > WebSphere-Anwendungsserver > Servername.Klicken Sie anschließend im Abschnitt "Serverinfrastruktur" auf Java- und Prozessverwaltung > Prozessdefinition > Java Virtual Machine |
Deployment Manager | Klicken Sie auf Systemverwaltung > Deployment Manager. Klicken Sie anschließend im Abschnitt "Serverinfrastruktur" auf Java- und Prozessverwaltung > Prozessdefinition > Java Virtual Machine |
Node Agent | Klicken Sie auf Systemverwaltung > Node Agent > Node_Agent. Klicken Sie anschließend im Abschnitt "Serverinfrastruktur" auf Java- und Prozessverwaltung > Prozessdefinition > Java Virtual Machine |
Gibt den Standardklassenpfad an, in dem der Code der virtuellen Java-Maschine (JVM) nach Klassen sucht.
Wenn Sie diesem Feld einen Klassenpfad hinzufügen müssen, geben Sie jeden einzelnen Klassenpfadeintrag in einer separaten Tabellenzeile an. Es ist nicht erforderlich, am Ende eines Eintrags einen Doppelpunkt bzw. ein Semikolon hinzuzufügen.
Datentyp | String |
Gibt die Klassen des Bootprogramms und die Ressourcen für den JVM-Code an. Diese Option ist nur für JVM-Anweisungen verfügbar, die Bootstrap-Klassen und -Ressourcen unterstützen.
Wenn Sie diesem Feld einen Klassenpfad hinzufügen müssen, geben Sie jeden einzelnen Klassenpfadeintrag in einer separaten Tabellenzeile an. Es ist nicht erforderlich, am Ende eines Eintrags einen Doppelpunkt bzw. ein Semikolon hinzuzufügen.
Wenn Sie dem Feld mehrere Klassenpfade hinzufügen müssen, können Sie je nach Betriebssystem, auf dem die JVM ausgeführt wird, einen Doppelpunkt (:) oder ein Semikolon (;) als Trennzeichen für die Klassenpfade verwenden.
Wenn Sie dem Feld mehrere Klassenpfade hinzufügen müssen, können Sie je nach Betriebssystem des Knotens einen Doppelpunkt (:) oder ein Semikolon (;) als Trennzeichen für die Klassenpfade verwenden.
Bei Auswahl dieser Option werden ausführliche Debug-Nachrichten zum Laden der Klasse ausgegeben. Standardmäßig wird der ausführliche Modus für das Laden von Klassen nicht aktiviert.
Wenn die ausführliche Ausgabe für das Laden von Klassen aktiviert ist, wird die Debug-Ausgabe an eines der nativen Prozessprotokolle gesendet.
Datentyp | Boolean |
Standardeinstellung | false |
Bei Auswahl dieser Option werden ausführliche Debug-Nachrichten zur Garbage-Collection ausgegeben. Standardmäßig ist die ausführliche Ausgabe nicht aktiviert.
Wenn die ausführliche Ausgabe für die Garbage-Collection aktiviert ist, wird die Debug-Ausgabe an eines der nativen Prozessprotokolle gesendet.
,
Datentyp | Boolean |
Standardeinstellung | false |
Bei Auswahl dieser Option wird bei jeder Ausführung des Garbage-Collectors ein Bericht in den Ausgabedatenstrom geschrieben. Dieser Bericht gibt Aufschluss darüber, wie der Java-Garbage-Collection-Prozess funktioniert.
83,29/3724,32 * 100 = 2,236 Prozent
Wenn die GC mehr als 5 % der Zeit benötigt und häufig ausgeführt wird, müssen Sie ggf. den Java-Heap-Speicher vergrößern.
Um festzustellen, ob der zugeordnete Heap-Speicher an Größe zunimmt, sehen Sie sich den Prozentsatz des Heap-Speichers an, der nach jedem Garbage-Collection-Zyklus nicht belegt ist, und stellen Sie sicher, dass dieser Prozentsatz nicht weiter abnimmt. Wenn der Prozentsatz an freiem Speicherplatz weiter abnimmt, nimmt die Größe des Heap-Speichers von Garbage-Collection zu Garbage-Collection allmählich zu. Diese Situation kann auf einen Speicherverlust in der Anwendung hinweisen.
Auf der Plattform z/OS können Sie die Informationen zum JVM-Heap-Speicher auch an der MVS-Konsole mit dem Befehl modify display,
jvmheap anzeigen. Zusätzlich können Sie die Datensätze zur Serveraktivität und die Intervall-SMF-Datensätze überprüfen. Die Größe des Java-Heap-Speichers steht auch der PMI
zur Verfügung und kann mit dem
Tivoli Performance Viewer überwacht werden.
Bei Auswahl dieser Option werden ausführliche Debug-Nachrichten zu den Aufrufen nativer Methoden ausgegeben. Standardmäßig ist die ausführliche Ausgabe für JNI-Aktivitäten nicht aktiviert.
Datentyp | Boolean |
Standardeinstellung | false |
Gibt die Anfangsgröße des Heap-Speichers für die JVM an. Wenn dieses Feld leer bleibt, wird der Standardwert verwendet.
Auf der Plattform z/OS ist die Standardeinstellung für
die Standardanfangsgröße des Heap-Speichers für den Controller 48 und für den Servant 128. Diese Standardwerte gelten für
31-Bit- und 64-Bit-Konfigurationen.
Für i5/OS und verteilte Plattformen ist die Standardanfangsgröße des Heap-Speichers
50 MB.
Die Startzeit kann sich verkürzen, wenn Sie den Wert für diese Einstellung erhöhen. Die Anzahl der Garbage-Collection-Durchläufe wird reduziert, wodurch eine Durchsatzsteigerung von 10 % realisiert werden kann.
Im Allgemeinen verbessert sich der Durchsatz durch Vergrößern des Java-Heap-Speichers, solange der Heap-Speicher in den physischen Speicher passt. Wenn die Größe des Heap-Speichers den verfügbaren physischen Speicher überschreitet und Paging stattfindet, nimmt die Leistung erheblich ab.
Gibt die maximale Größe des Heap-Speichers für die JVM an. Wenn dieses Feld leer bleibt, wird der Standardwert verwendet.
Für z/OS ist der Standardwert für die maximale Größe des Heap-Speichers 256 MB. Dieser Standardwert gilt für 31-Bit- und 64-Bit-Konfigurationen.
Die Startzeit kann sich verkürzen, wenn Sie die maximale Größe des Heap-Speichers erhöhen. Durch eine Erhöhung der maximalen Größe des Heap-Speichers können Sie die Anzahl der Garbage-Collection-Durchläufe reduzieren und damit eine Durchsatzsteigerung von 10 % realisieren.
Im Allgemeinen verbessert sich der Durchsatz durch das Erhöhen dieser Einstellung, solange der Heap-Speicher in den physischen Speicher passt. Wenn die Größe des Heap-Speichers den verfügbaren physischen Speicher überschreitet und Paging stattfindet, nimmt die Leistung erheblich ab. Deshalb ist es wichtig, dass der Wert, den Sie für diese Eigenschaft definieren, so gewählt ist, dass die physische Speicherkapazität für den Heap-Speicher ausreicht.
Um Paging zu verhindern, müssen Sie für diese Eigenschaft einen Wert angeben, der jedem
Prozessor mindestens 256 MB an physischem Hauptspeicher und jedem Anwendungsserver mindestens 512 MB an physischem Hauptspeicher
zugesteht.
Wenn die Prozessorauslastung wegen Pagings gering ist, erhöhen Sie, sofern möglich, den verfügbaren Speicher anstelle der maximalen Größe des Heap-Speichers.
Eine Erhöhung der maximalen Größe des Heap-Speichers kann die Leistung verringern, anstatt sie zu verbessern.
Wenn diese Eigenschaft auf der Plattform i5/OS auf 0 gesetzt wird,
wird der Garbage-Collector nur ausgeführt, wenn der Schwellenwert für den Garbage-Collector erreicht ist.
Wird ein anderer Wert als 0 angegeben, wird der Garbage-Collector ausgeführt, sobald die Heap-Speichergröße
den angegebenen Maximalwert erreicht.
Anders als bei der normalen Garbage-Collection müssen beim Erreichen der maximalen Größe jedoch allen Anwendungs-Threads
warten, bis der Garbage-Collection-Prozess abgeschlossen ist, und werden erst danach fortgesetzt.
Dies kann zu unerwünschten Wartezeiten führen. Deshalb sollten
Sie die maximale Heap-Speichergröße als Sicherheitsnetz verwenden, um Zeiten mit unerwartetem Anwachsen des Heap-Speichers
zu bewältigen und sicherzustellen, dass der Heap-Speicher nicht größer wird als der verfügbare Speicher.
Unter normalen Umständen sollte die angegebene maximale Heap-Speichergröße nicht erreicht werden.
Bei Auswahl dieser Option wird die Unterstützung für den HProf-Profiler aktiviert. Wenn Sie einen anderen Profiler verwenden möchten, geben Sie mit der Einstellung HProf-Argumente die Einstellungen für den angepassten Profiler an. Standardmäßig ist die Unterstützung für den HProf-Profiler nicht aktiviert.
Wenn Sie die Eigenschaft HProfs ausführen auf true einstellen, müssen Sie Befehlszeilenparameter für Profiler als Werte für die Eigenschaft HProf-Parameter angeben.
Datentyp | Boolean |
Standardeinstellung | false |
Gibt die Befehlszeilenparameter für Profiler an, die an den JVM-Code, der den Anwendungsserverprozess startet, übergeben werden sollen. Sie können nur dann Argumente angeben, wenn die Unterstützung für HProf-Profiler aktiviert ist.
HProf-Parameter sind nur erforderlich, wenn die Eigenschaft "HProfs ausführen" auf true eingestellt ist.
Gibt an, ob die JVM im Debug-Modus ausgeführt wird. Standardmäßig wird die Unterstützung für den Debug-Modus nicht aktiviert.
Wenn Sie die Eigenschaft Debug-Modus auf true einstellen, müssen Sie Debug-Befehlszeilenargumente als Werte für die Eigenschaft Debug-Argumente angeben.
Datentyp | Boolean |
Standardeinstellung | false |
Gibt die Befehlszeilenargumente für den Debugger an, die an den JVM-Code übergeben werden, der den Anwendungsserverprozess startet. Sie können Argumente angeben, wenn die Eigenschaft Debug-Modus auf true eingestellt ist.
Wenn Sie das Debugging in mehreren Anwendungsservern auf demselben Knoten aktivieren, müssen Sie sicherstellen, dass für das Adressargument nicht jedes Mal derselbe Wert angegeben wird. Das Adressargument definiert den Port, der für das Debugging verwendet wird. Wenn derselbe Debug-Port für zwei Server, in denen das Debugging aktiviert ist, konfiguriert wird, können die Server unter Umständen nicht ordnungsgemäß gestartet werden. Beispiel: Beide Server sind mit dem Debug-Argument address=7777 konfiguriert, dem Standardwert für das Debug-Adressargument.
Wenn Sie das Debugging in mehreren Anwendungsservern aktivieren, müssen Sie sicherstellen, dass für das Adressargument nicht jedes Mal derselbe Wert angegeben wird. Das Adressargument definiert den Port, der für das Debugging verwendet wird. Wenn derselbe Debug-Port für zwei Server, in denen das Debugging aktiviert ist, konfiguriert wird, können die Server unter Umständen nicht ordnungsgemäß gestartet werden. Beispiel: Beide Server sind mit dem Debug-Argument address=7777 konfiguriert, dem Standardwert für das Debug-Adressargument.
Datentyp | String |
Einheiten | Befehlszeilenargumente für Java |
Gibt die Befehlszeilenargumente an, die an den JVM-Code übergeben werden, der den Anwendungsserverprozess startet.
Geben Sie hotRestartSync an, um das Feature "Hot Restart Sync" des Synchronisationsservice zu aktivieren. Dieses Feature teilt dem Synchronisationsservice mit, dass die Installation in einer Umgebung ausgeführt wird, in der keine Konfigurationsaktualisierungen vorgenommen werden, wenn der Deployment Manager nicht gestartet ist. Deshalb muss der Service keinen vollständigen Repository-Vergleich durchführen, wenn der Deployment-Manager- oder Node-Agent-Server erneut gestartet wird. Wenn Sie dieses Feature aktivieren, verbessert sich die Effizienz der ersten Synchronisationsoperation nach einem Neustart von Deployment Manager oder Node Agent, insbesondere für Installationen, die Zellen mit unterschiedlichen Releases, mehreren Knoten und mehreren Anwendungen enthalten.
Geben Sie -Xverify:none an, wenn Sie die Phase mit der Überprüfung der Klassen beim Laden der Klassen überspringen möchten. Mit -Xverify:none wird die Java-Klassenüberprüfung inaktiviert, womit eine Verbesserung bei der Startzeit zwischen 10 und 15 % erreicht werden kann. Es werden jedoch keine beschädigten oder ungültigen Klassendaten gefunden, wenn dieses Argument angegeben ist. Wenn beschädigte Klassendaten geladen werden, kann die Java Virtual Machine (JVM) auf unerwartete Weise reagieren oder sogar ausfallen.
Geben Sie -Xnoclassgc an, wenn Sie die Garbage-Collection für Klassen inaktivieren möchten. Dieses Argument führt zu einer erhöhten Wiederverwendung von Klassen und einer geringfügig besseren Leistung. Die Ressourcen dieser Klassen bleiben jedoch im Gebrauch, selbst wenn die Klassen nicht aufgerufen werden. Sie können die Konfigurationseinstellung verbose:gc verwenden, wenn Sie die Garbage-Collection überwachen möchten. Anhand der Ausgabe können Sie den Leistungseinfluss der Zurückforderung dieser Ressourcen bestimmen. Wenn dieselben Klassen mehrfach von der Garbage-Collection erfasst werden, sollten Sie die Garbage-Collection inaktivieren. Die Garbage-Collection für Klassen ist standardmäßig aktiviert.
Geben Sie -Xgcthreads an, wenn Sie mehrere Garbage-Collection-Threads gleichzeitig verwenden möchten. Diese Garbage-Collection-Techniken sind als parallele Garbage-Collection bekannt. Dieses Argument ist nur für IBM Developer Kit gültig.
Wenn Sie diesen Wert im Feld Generische JVM-Argumente eingeben, geben Sie auch die Anzahl der Prozessoren an, die auf der Maschine ausgeführt werden. Werden beispielsweise drei Prozessoren auf der Maschine ausgeführt, geben Sie -Xgcthreads 3 an. Auf einem Knoten mit n Prozessoren sind standardmäßig n Threads verfügbar.
Geben Sie -Xnocompactgc an, wenn Sie die Komprimierung für den Heap-Speicher inaktivieren möchten. Die Komprimierung des Heap-Speichers ist die aufwendigste Garbage-Collection-Operation. Wenn Sie IBM Developer Kit verwenden, sollten Sie die Komprimierung des Heap-Speichers vermeiden. Wenn Sie die Komprimierung des Heap-Speichers inaktivieren, fällt der damit in Zusammenhang stehende Aufwand weg.
Geben Sie -Xgpolicy an, um die Garbage-Collection-Richtlinie festzulegen. Dieses Argument ist nur für IBM Developer Kit gültig.
Setzen Sie dieses Argument auf optavgpause, wenn eine gleichzeitige Markierung verwendet werden soll, um Anwendungs-Threads zu überwachen, die aus dem Stapel gestartet werden, bevor der Heap-Speicher erschöpft ist. Wenn Sie diesen Parameter angeben, werden lange Pausen vermieden und einheitlichere Pausen erreicht. Diese Richtlinie verringert jedoch den Durchsatz, weil Threads unter Umständen zusätzliche Arbeit übernehmen müssen.
Setzen Sie dieses Argument auf optthruput, wenn der Durchsatz optimiert werden soll und lange Pausen zwischen den Garbage-Collections kein Problem darstellen. Dies ist der Standardparameter und die empfohlene Einstellung.
Java Platform, Standard Edition 6 (Java SE 6) hat eine generationsabhängige Garbage-Collection, bei der unterschiedliche Speicherpools für Objekte mit unterschiedlichem Alter unterstützt werden. Im Garbage-Collection-Zyklus werden die Objekte unabhängig voneinander nach Alter erfasst. Mit zusätzlichen Parametern können Sie die Größe der Speicherpools einzeln festlegen. Um einen besseren Durchsatz zu erzielen, setzen Sie die Größe des Pools für Objekte mit kurzem Lebenszyklus so fest, dass der Lebenszyklus der Objekte im Pool die Dauer eines Garbage-Collection-Zyklus nicht überschreitet. Verwenden Sie die Parameter NewSize und MaxNewSize, um die Größe des Pools für die neue Generation festzulegen.
-XX:NewSize=unterer_Grenzwert -XX:MaxNewSize=oberer_Grenzwert -XX:SurvivorRatio=neues_Verhältnis
Geben Sie -Xminf an, um die Mindestgröße des freien Heap-Speichers in Prozent anzugeben. Der Heap-Speicher wächst an, wenn der frei Speicherplatz unter dem angegebenen Minimum liegt. Dieses Argument gibt im Modus mit unterstützter Rücksetzmöglichkeit den Mindestprozentsatz des freien Speicherplatzes für Middleware- und Übergangs-Heap-Speicher an. Der für dieses Argument angegebene Wert ist eine Gleitkommazahl zwischen 0 und 1. Der Standardwert ist .3 (30 Prozent).
Java HotSpot Technology in Java SE 6 verwendet eine adaptive JVM, die Algorithmen enthält, die nach und nach die Leistung des Bytecodes optimiert. Die JVM kann in zwei Modi ausgeführt werden: -server und -client. Sie sollten den Modus -server in den meisten Fällen verwenden. Dieser Modus bietet über einen längeren Zeitraum eine bessere Laufzeitleistung.
Wenn Sie den Standardmodus -client verwenden, ist die Serverstartzeit kürzer, und es entsteht weniger Speicherbedarf. Dieser Modus verringert jedoch die Leistung. Verwenden Sie den Modus -server, der eine bessere Leistung bietet, wenn die Leistung wichtiger ist als eine verkürzte Startzeit. Sie können die Prozessgröße und die Startzeit des Servers überwachen, um die Leistungsunterschiede zwischen den Modi -client und -server besser zu verstehen.
Dieses Argument gilt nur für z/OS. Geben Sie das Argument -Dcom.ibm.CORBA.RequestTimeout=Zeitlimitintervall an, um das Zeitlimit für die Beantwortung von Anforderungen, die vom Client gesendet werden, festzulegen. Dieses Argument wird mit der Option "-D" verwendet. Zeitlimitintervall ist das Zeitlimit in Sekunden. Falls es in Ihrem Netz eine extreme Latenzzeit gibt, geben Sie einen hohen Wert an, um Zeitlimitüberschreitungen zu vermeiden. Wenn Sie einen zu niedrigen Wert angeben, kann es bei einem am WLM beteiligten Anwendungsserver zu einer Zeitlimitüberschreitung kommen, bevor er eine Antwort empfangen hat.
Geben Sie dieses Argument nur dann an, wenn in Ihrer Anwendung Probleme wegen Zeitlimitüberschreitungen auftreten. Es gibt keine empfohlenen Werte für dieses Argument.
Dieses Argument gilt nur für z/OS. Geben Sie das Argument -Dcom.ibm.websphere.wlm.unusable.interval=Zeitlimitintervall an, um den Wert der Eigenschaft "com.ibm.websphere.wlm.unusable.interval" zu ändern, wenn der WLM-Status des Clients zu früh oder zu spät aktualisiert wird. Diese Eigenschaft gibt an, wie lange (in Sekunden) die Laufzeitumgebung des WLM-Clients nach der Kennzeichnung eines Servers als nicht verfügbar wartet, bis sie versucht, erneut Kontakt mit dem Server aufzunehmen. Dieses Argument wird mit der Option "-D" verwendet. . Der Standardwert sind 300 Sekunden. Falls Sie einen zu hohen Wert für diese Eigenschaft festlegen, bleibt der Server für einen langen Zeitraum als nicht verfügbar gekennzeichnet. Der WLM-Status des Clients wird erst nach Ablauf des angegebenen Zeitraums vom WLM-Aktualisierungsprotokoll aktualisiert.
Dieses Argument gilt nur für z/OS. Geben Sie das Argument -Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl= an, t vor, um anzugeben, dass der Speicher für einzelne direkte Bytepuffer freigegeben soll, sobald der Puffer nicht mehr benötigt wird. Der einzige unterstützte Wert für dieses Argument ist com.ibm.ws.buffermgmt.impl.ZOSWsByteBufferPoolManagerImpl.
-Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl=com.ibm.ws.buffermgmt.impl.ZOSWsByteBufferPoolManagerImpl
Auf der z/OS-Plattform müssen Sie dieses Argument auch angeben, wenn Sie die angepasste Eigenschaft
zaioFreeInitialBuffers für einen TCP-Channel angeben, um anzuzeigen, dass der Channel die anfänglichen
Lesepuffer, die in neuen Verbindungen verwendet werden, sofort freigeben soll, wenn sie für die Verbindung nicht mehr benötigt werden.
Geben Sie das Argument -Xshareclasses:none an, um die Option für gemeinsam Nutzung von Klassen für einen Prozess zu inaktivieren. Die Option für die gemeinsame Nutzung von Klassen, die in Java SE6 verfügbar ist, ermöglicht Ihnen die gemeinsame Nutzung von Klassen in einem Cache. Die gemeinsame Nutzung von Klassen in einem Cache kann die Startzeit verbessern und den Speicherbedarf verringern. Prozesse wie Anwendungsserver, Node Agents und Deployment Manager können die Option für gemeinsam Nutzung von Klassen verwenden.
Wenn Sie diese Option verwenden, sollten Sie den Cacheinhalt löschen, wenn der Prozess nicht verwendet wird. Zum Löschen des Cacheinhalts rufen Sie das Dienstprogramm "Stammverzeichnis_des_Anwendungsservers/bin/clearClassCache.bat/sh" auf, oder stoppen Sie den Prozess und starten ihn anschließend erneut.
Datentyp | String |
Einheiten | Befehlszeilenargumente für Java |
Gibt den vollständigen Pfadnamen einer vom JVM-Code verwendeten ausführbaren JAR-Datei an.
Datentyp | String |
Einheiten | Pfadname |
Gibt an, ob der JIT-Compiler des JVM-Codes inaktiviert werden soll.
Wenn Sie den JIT-Compiler inaktivieren, nimmt der Durchsatz merklich ab. Im Hinblick auf den Durchsatz sollte JIT deshalb aktiviert bleiben.
Datentyp | Boolean |
Standardeinstellung | false (JIT aktiviert) |
Empfohlene Einstellung | JIT aktiviert |
Die JVM-Einstellungen für ein bestimmtes Betriebssystem.
Beim Prozessstart verwendet der Prozess die JVM-Einstellungen, die für den Server angegeben wurde, als JVM-Einstellungen für das Betriebssystem.
Beim Prozessstart verwendet der Prozess die JVM-Einstellungen, die für den Knoten angegeben wurde, als JVM-Einstellungen für das Betriebssystem.
Bei Auswahl dieser Option werden ausführliche Debug-Nachrichten zur Garbage-Collection ausgegeben. Standardmäßig ist die ausführliche Ausgabe nicht aktiviert.
Wenn die ausführliche Ausgabe für die Garbage-Collection aktiviert ist, wird die Debug-Ausgabe an eines der nativen Prozessprotokolle gesendet.
,
Datentyp | Boolean |
Standardeinstellung | false |
Bei Auswahl dieser Option wird bei jeder Ausführung des Garbage-Collectors ein Bericht in den Ausgabedatenstrom geschrieben. Dieser Bericht gibt Aufschluss darüber, wie der Java-Garbage-Collection-Prozess funktioniert.
83,29/3724,32 * 100 = 2,236 Prozent
Wenn die GC mehr als 5 % der Zeit benötigt und häufig ausgeführt wird, müssen Sie ggf. den Java-Heap-Speicher vergrößern.
Um festzustellen, ob der zugeordnete Heap-Speicher an Größe zunimmt, sehen Sie sich den Prozentsatz des Heap-Speichers an, der nach jedem Garbage-Collection-Zyklus nicht belegt ist, und stellen Sie sicher, dass dieser Prozentsatz nicht weiter abnimmt. Wenn der Prozentsatz an freiem Speicherplatz weiter abnimmt, nimmt die Größe des Heap-Speichers von Garbage-Collection zu Garbage-Collection allmählich zu. Diese Situation kann auf einen Speicherverlust in der Anwendung hinweisen.
Auf der Plattform z/OS können Sie die Informationen zum JVM-Heap-Speicher auch an der MVS-Konsole mit dem Befehl modify display,
jvmheap anzeigen. Zusätzlich können Sie die Datensätze zur Serveraktivität und die Intervall-SMF-Datensätze überprüfen. Die Größe des Java-Heap-Speichers steht auch der PMI
zur Verfügung und kann mit dem
Tivoli Performance Viewer überwacht werden.
Mit (online) gekennzeichnete Links setzen einen Internet-Zugang voraus.