JVM-Einstellungen

83,29/3724,32 * 100 = 2,236 Prozent

Wenn die Garbage-Collection mehr als 5 % der Zeit benötigt und häufig ausgeführt wird, müssen Sie ggf. den Java-Heapspeicher vergrößern.

Um festzustellen, ob der zugeordnete Heapspeicher wächst, sehen Sie sich den Prozentsatz des nicht zugeordneten Heapspeichers nach jedem Garbage-Collection-Zyklus an, und vergewissern Sie sich, dass der Prozentsatz nicht weiter abnimmt. Wenn der Prozentsatz des freien Speicherbereichs weiter abnimmt, steigt die Heapspeichergröße mit jeder Garbage-Collection allmählich an. Diese Situation kann auf Speicherverluste in Ihrer Anwendung hinweisen.

Geben Sie -DhotRestartSync 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, vielen Knoten und vielen Anwendungen enthalten.

Setzen Sie diese Option auf true, wenn Sie die Funktion Advanced Encryption Standard (AES), die mit IBM SDK and Runtime Environment for AIX, Java Technology Edition, Version 7 bereitgestellt wird. AES ist eine symmetrische Blockchiffrierung, die Daten über mehrere Runden verschlüsselt und entschlüsselt. Die Aktivierung dieser Funktion führt zu Leistungsverbesserungen in der SSL-Verarbeitung von WebSphere Application Server.

Sie können -Xverify:none verwenden, 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.

Fehler vermeiden:

• Verwenden Sie dieses Argument nicht, wenn Sie Änderungen am Bytecode vornehmen, da die JVM beim Auftreten von Instrumentierungsfehlern ausfallen kann.
• Sollte die JVM, wenn dieses Argument wirksam ist, ausfallen oder unerwartet reagieren, entfernen Sie dieses Argument, wenn Sie Ihr JVM-Problem untersuchen.
• Dieses Argument wird unter IBM i nicht unterstützt.

gotcha

Geben Sie -Xnoclassgc an, um die Garbage-Collection nach Klassen zu inaktivieren. Dieses Argument führt zu einer erhöhten Wiederverwendung von Klassen und einer geringfügig besseren Leistung. Die Ressourcen, deren Eigner diese Klassen sind, werden jedoch weiterhin verwendet, wenn die Klassen nicht aufgerufen werden.

Fehler vermeiden: Der Leistungseinfluss der Garbage-Collection für Klassen ist gewöhnlich minimal, und die Inaktivierung der Garbage-Collection für Klassen auf einem Java-EE-basierten System (Java Platform, Enterprise Edition) mit starker Nutzung von Anwendungsklassenladern kann einen Speicherverlust bei den Klassendaten hervorrufen und dazu führen, dass die JVM eine Ausnahme wegen abnormaler Speicherbedingungen auslöst. gotcha

Sie können die Konfigurationseinstellung verbose:gc verwenden, wenn Sie die Garbage-Collection überwachen möchten. Anhand der Ausgabe können Sie die Auswirkung der Neuanforderung dieser Ressourcen auf die Leistung bestimmen.

Wenn Sie bei der erneuten Implementierung einer Anwendung das Argument "-Xnoclassgc" angeben, müssen Sie den Anwendungsserver immer erneut starten, damit die Klassen und statischen Daten der vorherigen Version der Anwendung bereinigt werden.

Fehler vermeiden: Dieses Argument wird unter IBM i nicht unterstützt. Sie müssen das Argument -noclassgc verwenden, um die Garbage-Collection für Klassen auf dieser Plattform zu inaktivieren.gotcha

Geben Sie -Xgcthreads an, wenn Sie mehrere Garbage-Collection-Threads gleichzeitig verwenden möchten. Diese Garbage-Collection-Techniken werden als parallele Garbage-Collection bezeichnet. 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 ein, die auf der Maschine ausgeführt werden.

Geben Sie -Xgcthreads wie folgt an:

-Xgcthreads<Anzahl der Prozessoren>

Fehler vermeiden: Fügen Sie zwischen --Xgcthreads und dem Wert n, der die Anzahl der Prozessoren angibt, kein Leerzeichen ein.

-Xgcthreads5 ist ein Beispiel für die Angabe von -Xgcthreads mit 5 Prozessoren.

gotcha

Bewährtes Verfahren: Sie müssen parallele Garbage-Collection verwenden, wenn Ihre Maschine mehrere Prozessoren hat.bprac

Fehler vermeiden: Dieses Argument wird unter IBM i nicht unterstützt. gotcha

Geben Sie -Xnocompactgc an, wenn Sie die Komprimierung des Heapspeichers inaktivieren möchten. Die Komprimierung des Heapspeichers ist die kostenintensivste Garbage-Collection-Operation. Wenn Sie IBM Developer Kit verwenden, müssen Sie die Komprimierung des Heapspeichers vermeiden. Wenn Sie die Komprimierung des Heapspeichers inaktivieren, fällt der damit in Zusammenhang stehende Aufwand weg.

Fehler vermeiden: Dieses Argument wird unter IBM i nicht unterstützt. gotcha

Geben Sie -Xgcpolicy an, um die Garbage-Collection-Richtlinie festzulegen. Dieses Argument ist nur für IBM Developer Kit gültig.

Setzen Sie dieses Argument auf optthruput, wenn Sie den Durchsatz optimieren möchten und keine Probleme entstehen, wenn lange Pausen zwischen den Garbage-Collections eingehalten werden.

Setzen Sie dieses Argument auf gencon, wenn Sie einen Garbage-Collector verwenden, der die Garbage-Collection nach Objektalter durchführt. Mit Hilfe des Schemas nach Objektalter wird versucht, einen hohen Durchsatz bei geringeren Wartezeiten während der Garbage-Collection zu erzielen. Dazu wird der Heapspeicher in zwei Generationen, neue und alte Segmente unterteilt. Langlebige Objekte werden dem alten Speicher zugeordnet, während kurzlebige Objekte im neuen Speicher schnell durch die Garbage-Collection bereinigt werden. Die Richtlinie "gencon" hat für viele Anwendungen erhebliche Vorteile. Sie eignet sich jedoch nicht für alle Anwendungen und ist gewöhnlich schwer zu optimieren.

Setzen Sie dieses Argument auf optavgpause, wenn Sie die gleichzeitige Markierung verwenden möchten, um Anwendungsthreads zu überwachen, die aus dem Stack gestartet werden, bevor der Heapspeicher erschöpft ist. Auf diese Weise werden lange Pausen vermieden und einheitlichere Pausen erreicht. Die Verwendung dieser Richtlinie verringert jedoch den Durchsatz, weil die Threads zusätzliche Operationen ausführen müssen.

Setzen Sie dieses Argument auf subpool, wenn Sie die Leistung von Multiprozessorsystemen erhöhen möchten, in denen gewöhnlich mehr als acht Prozessoren verwendet werden. Diese Richtlinie ist nur für Prozessoren auf IBM System i, System p und System z verfügbar. Die Richtlinie "subpool" gleicht der Richtlinie "optthruput", allerdings wird der Heapspeicher in Speicherteilbereiche unterteilt, die eine bessere Skalierbarkeit für die Objektzuordnung bieten.

Fehler vermeiden: Dieses Argument wird unter IBM i nicht unterstützt. gotcha

Java Platform, Standard Edition 6 (Java SE 6) unterstützt die 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 kurzlebige Objekte so fest, dass die Lebensdauer der Objekte im Pools die Dauer eines Garbage-Collection-Zyklus nicht überschreiten. 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 

Bewährtes Verfahren: Bei einer JVM mit einer Heapspeichergröße von mehr als 1 GB müssen Sie jedoch die folgenden Werte verwenden:

• -XX:NewSize=640m
• -XX:MaxNewSize=640m
• -XX:SurvivorRatio=16

bprac

Alternativ können Sie 50 % bis 60 % der Gesamtgröße des Heapspeichers für einen neuen Generationspool festlegen.

Fehler vermeiden: Dieses Argument wird unter IBM i nicht unterstützt. gotcha

Geben Sie -Xminf an, wenn Sie die Mindestgröße des freien Heapspeichers in Prozent ändern möchten. Der Heapspeicher 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 Übergangsheapspeicher an. Der für dieses Argument angegebene Wert ist eine Gleitkommazahl zwischen 0 und 1. Der Standardwert ist .3 (30 Prozent).

Fehler vermeiden: Dieses Argument wird unter IBM i nicht unterstützt. gotcha

Java HotSpot Technology in Java SE 6 verwendet eine adaptive JVM die Algorithmen enthält, die die Leistung des Bytecodes mit der Zeit optimiert. Die JVM kann in zwei Modi ausgeführt werden: -server und -client. Sie sollten den Modus -server in den meisten Fällen. Dieser Modus unterstützt eine effizientere Laufzeitleistung über einen längeren Zeitraum.

Wenn Sie den Standardmodus -client verwenden, ist die Startzeit kürzer und der Speicherbedarf geringer. Dieser Modus verringert jedoch langfristig die Leistung. Verwenden Sie den Modus -server, der die Leistung verbessert nur, wenn die Startzeit von höherer Bedeutung ist als die Leistung. Sie können die Prozessgröße und die Startzeit des Servers überwachen, um die Leistungsunterschiede zwischen den Modi -client und -server besser zu verstehen.

Fehler vermeiden: Dieses Argument wird unter IBM i nicht unterstützt. gotcha

Geben Sie das Argument -Dcom.ibm.CORBA.RequestTimeout= Zeitlimit an, um das Zeitlimit für die Beantwortung von Anforderungen festzulegen, die der Client sendet. 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 an, wenn in Ihrer Anwendung Probleme mit Zeitlimitüberschreitungen auftreten. Es gibt keine empfohlenen Werte für dieses Argument.

Das Argument -Dcom.ibm.server.allow.sigkill=true ermöglicht dem Node-Agent-Prozess die Verwendung der Methode "terminate" eines Prozesses, wenn die Methode "stop" nicht innerhalb des für Ping definierten Zeitintervalls abgeschlossen wird. Diese Einstellung ist hilfreich, wenn der Node Agent einen Anwendungsserver überwacht und den Kontakt zu diesem Anwendungsserver verliert.

Wenn die Überwachungsrichtlinie für den Anwendungsserver dem Node Agent den Neustart des Anwendungsservers ermöglicht, weil der automatische Neustart für den Anwendungsserver aktiviert ist, führt der Node Agent die Methode "stop" im Anwendungsserverprozess aus. Während der Stoppverarbeitung überwacht der Node Agent den Anwendungsserver. Wenn der Anwendungsserver nicht innerhalb des für Ping angegebenen Zeitintervalls gestoppt wird und dieses Argument auf true (den Standardwert) gesetzt ist, führt der Node Agent die Methode "terminate" im Anwendungsserverprozess aus, um den Anwendungsserverprozess zu stoppen.

Wenn Sie dieses Argument auf false setzen, setzt der Node Agent die Überwachung des Stoppprozesses fort, versucht aber nicht, den Anwendungsserver erneut zu starten.

Wenn Sie die Administrationskonsole zum Inaktivieren dieses Arguments verwenden möchten, klicken Sie auf Systemverwaltung > Node Agents > Name_des_Node_Agent > Java- & Prozessverwaltung > Prozessdefinition > Java Virtual Machine > Generische JVM-Argumente.

Dieses Argument gibt an, wie oft ein Alarm seinen vollständigen Stack-Trace in Nachrichten aufgrund blockierter Threads in die Systemprotokolle schreiben kann.

Wenn ein Alarmthread des Systems länger aktiv ist, als durch den Grenzwert des Alarmthreadmonitors festgelegt, protokolliert der Anwendungsserver eine Nachricht aufgrund blockierter Threads, die den Namen des Alarmthreads, den Aktivitätszeitraum des Alarmthreads und den vollständigen Ausnahmebedingungs-Stack-Trace enthält. Der vollständige Stack-Trace ist nützlich, wenn es darum geht, die Ursache der Verzögerung zu beheben, doch wenn Nachrichten aufgrund blockierter Threads häufig ausgelöst werden, kann das dazu führen, dass andere Informationen in den Systemprotokollen schwer zu finden sind. Setzen Sie dieses Argument auf einen ganzzahligen Wert größer als 0, um anzugeben, wie oft ein einzelner Alarm seinen vollständigen Stack-Trace melden kann. Wenn dieser Grenzwert erreicht ist, enthält jede nachfolgende Nachricht, die aufgrund blockierter Threads ausgegeben wird, nur den Eintrag des blockierten Alarmhandlers.

Der Standardwert 0 zeigt an, dass alle Nachrichten aufgrund blockierter Threads für einen Alarm den vollständigen Stack-Trace enthalten.

Geben Sie dieses Argument an, um vor alle Debugnachrichten des Servers, die Ausgabe für die Protokolldateien "native_stdout" und "native_stderr" sind, eine Zeitmarke und eine Threadkennung zu setzen. Sie können die Zeitmarke und die Thread-ID verwenden, um das Verhalten der verschiedenen Bootstrapkomponenten des Anwendungsservers zum Verhalten anderer Servermechanismen, die in den Protokolldateien "SystemOut" und "SystemErr" angezeigt werden, in Beziehung zu setzen. Dieses Verhalten ist standardmäßig inaktiviert.

Wenn der Server mit dem generischen JVM-Argument -Dws.ext.debug=true konfiguriert wird, gibt er während der Bootstrapping-Sequenz Debugnachrichten in die Protokolldateien "native_stdout.log" und "native_stderr.log" aus. Wenn -Dcom.ibm.websphere.native.logging.timestamp ebenfalls auf true gesetzt ist, gibt der Server wie im folgenden Beispiel Debugnachrichten mit Zeitmarke und Thread-ID aus:

[6/18/12 16:24:31:453 CDT] 00000000 
ws.ext.mains.args[0]=-nosplash
[6/18/12 16:24:31:453 CDT] 00000000 
ws.ext.mains.args[1]=-application
[6/18/12 16:24:31:453 CDT] 00000000 
ws.ext.mains.args[2]=com.ibm.ws.bootstrap.WSLauncher
[6/18/12 16:24:31:453 CDT] 00000000 
ws.ext.mains.args[3]=com.ibm.ws.runtime.WsServer

Dieses Argument gilt nur für z/OS. Geben Sie das Argument -Dcom.ibm.websphere.wlm.unusable.interval= Zeitlimit an, um den Wert der Eigenschaft "com.ibm.websphere.wlm.unusable.interval" zu ändern, wenn der Workload-Management-Status des Clients zu früh oder zu spät aktualisiert wird. Diese Eigenschaft definiert das Zeitintervall, das die Laufzeitumgebung des WLM-Clients abwartet, nachdem sie einen Server als nicht verfügbar gekennzeichnet hat und bevor sie versucht, erneut Kontakt zu dem Server aufzunehmen. Dieses Argument wird mit der Option "-D" verwendet. Der Standardwert ist 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. Mit dem Argument -Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl= können Sie angeben, dass der Speicher für einzelne direkte Bytepuffer freigegeben werden 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 Plattform z/OS müssen Sie dieses Argument auch angeben, wenn Sie die angepasste Eigenschaft zaioFreeInitialBuffers für einen TCP-Kanal angeben, damit der Kanal die anfänglichen Lesepuffer für neue Verbindungen freigibt, sobald sie für die Verbindung nicht mehr benötigt werden.

Gibt an, ob die SIP-Konformitätsprüfung im SIP-Proxy-Server aktiviert ist. Durch die SIP-Konformitätsprüfung wird sichergestellt, dass die SIP-Nachrichten dem Standard "Session Initiation Protocol" entsprechen. Wenn Sie diese Eigenschaft auf true setzen, wird die SIP-Konformitätsprüfung aktiviert.

Fehler vermeiden: Wenn Sie einen Proxy-Server in einer z/OS-Umgebung mit WebSphere Application Server Network Deployment ausführen und Ihr Proxy-Server nicht zu einem Cluster gehört, können Sie die angepasste Eigenschaft "isSipComplianceEnabled" des SIP-Proxy-Servers verwenden, um die SIP-Konformitätsprüfung für diesen SIP-Proxy-Server zu aktivieren oder zu inaktivieren. Verwenden Sie jedoch einen eigenständigen Anwendungsserver oder gehört der Proxy-Server zu einem Cluster, müssen Sie dieses generische JVM-Argument verwenden, um die SIP-Konformitätsprüfung zu aktivieren oder zu inaktivieren.gotcha

Mit dem Argument -Xshareclasses:none können Sie die Option für gemeinsam Nutzung von Klassen für einen Prozess inaktivieren. Die Option für die gemeinsame Nutzung von Klassen, die in Java SE 6 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, müssen Sie den Cache 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 Sie stoppen den Prozess und starten ihn anschließend erneut.

Fehler vermeiden:

• Die IBM JVM for J2SE 5 wird unter Solaris, HP und IBM i nicht unterstützt.
• In einem Anwendungsserverprozess ausgeführte Java-EE-Anwendungsklassen werden dem Cache für gemeinsam genutzte Klassen nicht hinzugefügt.

gotcha

Verwenden Sie das Argument -XXallowvmshutdown:false, um die JVM, die nicht ordnungsgemäß ausgeführt wird, zu einem vorheriges Verhalten zurückzuversetzen. Java 5.0 SR10 und Java 6 SR5 korrigieren Problemstellungen, in denen die Java Virtual Machine (JVM) nicht ordnungsgemäß heruntergefahren wird. Wenn Sie eine Anwendung haben, die vom alten Verhalten abhängig ist, können Sie, indem Sie dieses Argument zum Abschnitt "Generische JVM-Argumente" hinzufügen, zum vorherigen Verhalten zurückwechseln.