JVM-Einstellungen

Verwenden Sie diese Seite, um die Konfigurationseinstellungen der JVM (Java™ Virtual Machine) eines Prozesses für einen Anwendungsserver anzuzeigen und zu ändern.

Wenn Sie diese Seite der Administrationskonsole anzeigen möchten, stellen Sie eine Verbindung zur Administrationskonsole her, und navigieren Sie zur Anzeige "Java Virtual Machine".

[z/OS]Verwenden Sie für die Plattform z/OS einen der folgenden Pfade:
Information Wert
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-Name. Klicken Sie anschließend im Abschnitt "Serverinfrastruktur" auf Java- und Prozessverwaltung > Prozessdefinition > Java Virtual Machine
[AIX Solaris HP-UX Linux Windows][IBM i]Für IBM i und verteilte Plattformen folgen Sie einem der folgenden Pfade.
Information Wert
Anwendungsserver Server > Servertypen > WebSphere-Anwendungsserver > Servername . Klicken Sie anschließend im Abschnitt "Serverinfrastruktur" auf Java- und Prozessverwaltung > Prozessdefinition > Java Virtual Machine
Deployment Manager Systemverwaltung > Deployment Manager. Klicken Sie anschließend im Abschnitt "Serverinfrastruktur" auf Java- und Prozessverwaltung > Prozessdefinition > Java Virtual Machine
Node Agent Systemverwaltung > Node Agent > Node-Agent-Name. Klicken Sie anschließend im Abschnitt "Serverinfrastruktur" auf Java- und Prozessverwaltung > Prozessdefinition > Java Virtual Machine

Klassenpfad

Gibt den Standardklassenpfad an, in dem der Code der Java Virtual Machine 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.

Die einzigen Klassenpfade, die diesem Feld hinzugefügt werden sollten, sind die Klassenpfad, die die Positionen der folgenden Komponenten angeben:
  • Prüf- oder Überwachungstool für Ihr System,
  • JAR-Dateien für ein Produkt, das auf der Basis dieses Produkts ausgeführt wird,
  • Patch-Codes oder -Fixes für die JVM-Diagnose.
Es können Verarbeitungsfehler auftreten, wenn Sie diesem Feld Klassenpfade hinzufügen, die die Positionen der folgenden Komponenten angeben:
  • JAR-Dateien für Ressourcenprovider, wie z. B. DB2. Die Pfade dieser JAR-Dateien müssen den entsprechenden Providerklassenpfaden hinzugefügt werden.
  • JAR-Dateien von Benutzern, die von einer oder mehreren Anwendungen verwendet werden, die Sie im Produkt ausführen. Der Pfad dieser Art von JAR-Dateien muss in jeder Anwendung, die diese JAR-Datei erfordert, oder in gemeinsam genutzten Bibliotheken angegeben werden, die dem Server zugeordnet sind.
  • JAR-Dateien für Erweiterungen. Wenn Sie Ihrem System eine JAR-Datei für eine Erweiterung hinzufügen müssen, müssen Sie die angepasste JVM-Eigenschaft "ws.ext.dirs" verwenden, um den absoluten Pfad dieser JAR-Datei anzugeben. Sie können die JAR-Datei auch in das Verzeichnis WAS_HOME/lib/ext/ stellen, aber die Verwendung der angepassten JVM-Eigenschaft ws.ext.dirs ist die empfohlene Methode für die Angabe des Pfads einer JAR-Datei für eine Erweiterung.
Information Wert
Datentyp String

Boot-Klassenpfad

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 Klassen des Bootprogramms 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 des Knotens einen Doppelpunkt (:) oder ein Semikolon (;) als Trennzeichen für die Klassenpfade verwenden.

Die einzigen Klassenpfade, die diesem Feld hinzugefügt werden sollten, sind die Klassenpfad, die die Positionen der folgenden Komponenten angeben:
  • Prüf- oder Überwachungstool für Ihr System,
  • JAR-Dateien für ein Produkt, das auf der Basis dieses Produkts ausgeführt wird,
  • Patch-Codes oder -Fixes für die JVM-Diagnose.
Es können Verarbeitungsfehler auftreten, wenn Sie diesem Feld Klassenpfade hinzufügen, die die Positionen der folgenden Komponenten angeben:
  • JAR-Dateien für Ressourcenprovider, wie z. B. DB2. Die Pfade dieser JAR-Dateien müssen den entsprechenden Providerklassenpfaden hinzugefügt werden.
  • JAR-Dateien von Benutzern, die von einer oder mehreren Anwendungen verwendet werden, die Sie im Produkt ausführen. Der Pfad dieser Art von JAR-Dateien muss in jeder Anwendung, die diese JAR-Datei erfordert, oder in gemeinsam genutzten Bibliotheken angegeben werden, die dem Server zugeordnet sind.
  • JAR-Dateien für Erweiterungen. Wenn Sie Ihrem System eine JAR-Datei für eine Erweiterung hinzufügen müssen, müssen Sie die angepasste JVM-Eigenschaft "ws.ext.dirs" verwenden, um den absoluten Pfad dieser JAR-Datei anzugeben. Sie können die JAR-Datei auch in das Verzeichnis WAS_HOME/lib/ext/ stellen, aber die Verwendung der angepassten JVM-Eigenschaft ws.ext.dirs ist die empfohlene Methode für die Angabe des Pfads einer JAR-Datei für eine Erweiterung.

Ausführliche Ausgabe zum Laden der Klasse

Gibt an, ob ausführliche Debug-Nachrichten zum Laden der Klasse ausgegeben werden. Der Standardwert sieht vor, den ausführlichen Modus für das Klassenladen nicht zu aktivieren.

[AIX Solaris HP-UX Linux Windows]Wenn der ausführliche Modus für das Klassenladen aktiviert ist, wird die Debug-Ausgabe an eines der nativen Prozessprotokolle gesendet.

Information Wert
Datentyp Boolean
Standardwert false

Ausführliche Ausgabe zur Garbage-Collection

Gibt an, ob ausführliche Debug-Nachrichten zur Garbage-Collection ausgegeben werden. Der Standardwert sieht vor, den ausführlichen Modus für die Garbage-Collection nicht zu aktivieren.

[AIX Solaris HP-UX Linux Windows]Wenn der ausführliche Modus für die Garbage-Collection aktiviert ist, wird die Debug-Ausgabe an eines der nativen Prozessprotokolle gesendet.

Information Wert
Datentyp Boolean
Standardwert false

Bei Auswahl dieser Option wird bei jeder Ausführung des Garbage-Collectors ein Bericht in den Ausgabedatenstrom geschrieben. Dieser Bericht gibt Ihnen einen Überblick über die Funktionsweise des Java-Garbage-Collection-Prozesses.

Sie können den verboseGC-Bericht verwenden, um Folgendes zu ermitteln:
  • Zeit, die die JVM für die Garbage-Collection aufbringt.
    Im Idealfall sollte die JVM weniger als 5 Prozent seiner Verarbeitungszeit für die Garbage-Collection aufwenden. Sie können den Prozentsatz der für die Garbage-Collection erforderlichen Zeit berechnen, indem Sie die Zeit bis zum Abschluss der Garbage-Collection durch die Zeit seit dem letzten AF dividieren und das Ergebnis mit 100 multiplizieren. Beispiele:
    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.

  • Ob der zugeordnete Heapspeicher mit jeder Garbage-Collection anwächst.

    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.

[z/OS]Auf der Plattform z/OS können Sie die Informationen zum JVM-Heapspeicher auch mit dem MVS-Konsolbefehl 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 JVM-Heapspeichers steht auch der PMI zur Verfügung und kann mit dem Tivoli Performance Viewer überwacht werden.

Ausführliche Ausgabe zu JNI

Bei Auswahl dieser Option werden ausführliche Debug-Nachrichten zu den Aufrufen nativer Methoden ausgegeben. Standardmäßig wird der ausführliche Modus für JNI-Aktivitäten (Java Native Interface) nicht aktiviert.

Information Wert
Datentyp Boolean
Standardwert false

Anfangsgröße des Heapspeichers

Gibt die Anfangsgröße des Heapspeichers (in MB) an, die dem JVM-Code zur Verfügung steht. Wenn dieses Feld leer bleibt, wird der Standardwert verwendet.

[z/OS]Unter z/OS ist der Standardwert für die Anfangsgröße des Heapspeichers 256 MB für den Controller und 512 MB für den Servant.

[AIX Solaris HP-UX Linux Windows][IBM i]Auf IBM i und verteilten Plattformen ist der Standardwert für die Anfangsgröße des Heapspeichers 50 MB.

Bewährtes Verfahren Bewährtes Verfahren: Die Standardwerte sind für die meisten Anwendungen ausreichend.bprac
Fehler vermeiden Fehler vermeiden: Auf der Plattform IBM i muss die Anfangsgröße des Heapspeichers immer kleiner sein als die maximale Größe des Heapspeichers. Verwenden Sie für die beiden Eigenschaften nie denselben Wert. gotcha

Die Startzeit kann sich verkürzen, wenn Sie den Wert dieser 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-Heapspeichers so lange, bis der Heapspeicher zu groß für den physischen Speicher wird. Wenn die Größe des Heapspeichers die Größe des verfügbaren physischen Hauptspeichers überschreitet und Paging stattfindet, nimmt die Leistung merklich ab.

Maximalgröße des Heapspeichers

Gibt die maximale Größe des Heapspeichers (in MB) für den JVM-Code an. Wenn dieses Feld leer bleibt, wird der Standardwert verwendet.

Der Standardwert für die maximale Größe des Heapspeichers beträgt 25 % des Gesamtsystemspeichers bis zu einer Speichergröße von 4 GB bzw. entspricht dem JVM-Standardwert, wenn kein Zugriff auf die Speichergröße möglich ist.

Die Startzeit kann sich verkürzen, wenn Sie die Maximalgröße für den Heapspeicher heraufsetzen. Durch eine Erhöhung der maximalen Größe des Heapspeichers 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 Vergrößern dieser Einstellung, bis der Heapspeicher zu groß für den physischen Speicher wird. Wenn die Größe des Heapspeichers die Größe des verfügbaren physischen Hauptspeichers überschreitet und Paging stattfindet, nimmt die Leistung merklich ab. Deshalb ist es wichtig, den Wert für diese Einstellung so zu definieren, dass die physische Speicherkapazität für den Heapspeicher ausreicht.

[z/OS]Unter z/OS ist der Standardwert für die maximale Größe des Heapspeichers 512 MB für den Controller und der Standardwert für die Anfangsgröße des Heapspeichers beträgt 1024 MB für den Servant. 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 zuteilt. Wenn die Prozessorauslastung aufgrund des Pagings gering ist, erhöhen Sie möglichst den verfügbaren Speicher und nicht die maximale Größe des Heapspeichers. Eine Erhöhung der maximalen Größe des Heapspeichers kann zu einem Leistungsabfall führen.

Bewährtes Verfahren Bewährtes Verfahren: Die Standardwerte sind für die meisten Anwendungen ausreichend. Aktivieren Sie die Eigenschaft Ausführliche Garbage-Collection, wenn Sie der Meinung sind, dass die Garbage-Collection zu häufig durchgeführt wird. Wenn die Garbage-Collection zu häufig stattfindet, erhöhen Sie die maximale Größe des JVM-Heapspeichers.bprac
[AIX Solaris HP-UX Linux Windows][IBM i]

HProf ausführen

Gibt an, ob die Unterstützung für den HProf-Profiler aktiviert ist. Wenn Sie einen anderen Profiler verwenden möchten, geben Sie die angepassten Profiler-Einstellungen über die HProf-Parameter ein. Der Standardwert sieht vor, die HProf-Profiler-Unterstützung nicht zu aktivieren.

Wenn Sie die Eigenschaft HProfs ausführen auf true setzen, müssen Sie Befehlszeilenparameter für Profiler als Werte für die Eigenschaft HProf-Parameter angeben.

Information Wert
Datentyp Boolean
Standardwert false
[AIX Solaris HP-UX Linux Windows][IBM i]

HProf-Argumente

Gibt die Befehlszeilenparameter für Profiler an, die an den JVM-Code, der den Anwendungsserverprozess startet, übergeben werden sollen. Sie können Parameter 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.

Debug-Modus

Gibt an, ob die JVM im Debug-Modus ausgeführt werden soll. Standardmäßig wird der Debug-Modus nicht aktiviert.

Wenn Sie die Eigenschaft Debug-Modus auf true setzen, müssen Sie Befehlszeilenparameter für das Debugging als Werte für die Eigenschaft Debug-Parameter angeben.

Information Wert
Datentyp Boolean
Standardwert false

Debug-Argumente

Gibt die Debug-Befehlszeilenparameter an, die an den JVM-Code, der den Anwendungsserverprozess startet, übergeben werden sollen. Sie können Argumente angeben, wenn die Eigenschaft Debug-Modus auf true gesetzt ist.

Wenn Sie das Debugging in mehreren Anwendungsservern auf demselben Knoten aktivieren, müssen Sie sicherstellen, dass für das Argument "Adresse" nicht derselbe Wert angegeben wird. Das Argument "Adresse" definiert den Port, der für das Debugging verwendet wird. Wenn für zwei Server, für die das Debugging aktiviert ist, derselbe Debug-Port konfiguriert ist, werden die Server möglicherweise nicht ordnungsgemäß gestartet. Beide Server könnten beispielsweise noch mit dem Debug-Argument address=7777 konfiguriert sein, dem Standardwert für das Argument "Adresse".

Information Wert
Datentyp String
Einheiten Java-Befehlszeilenargumente

Generische JVM-Argumente

Gibt die Befehlszeilenparameter an, die an den JVM-Code übergeben werden, der den Anwendungsserverprozess startet.

Sie können die folgenden optionalen Befehlszeilenargumente im Feld Generische JVM-Argumente eingeben. Wenn Sie mehrere Argumente eingeben, müssen Sie ein Leerzeichen als Trennzeichen zwischen den Argumenten verwenden.
Fehler vermeiden Fehler vermeiden: Wenn das Argument nur für IBM Developer Kit bestimmt ist kann es nicht mit einer JVM eines anderen Anbieters, z. B. einer JVM von Microsoft oder Hewlett-Packard, verwendet werden.gotcha
  • [z/OS][AIX Solaris HP-UX Linux Windows]-DhotRestartSync:

    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.

  • -Dcom.ibm.crypto.provider.doAESInHardware:

    Setzen Sie diese Option auf true, wenn die Funktion AES (Advanced Encryption Standard), die mit IBM SDK und Runtime Environment for AIX, Java Technology Edition Version 7, bereitgestellt wird, aktiviert werden soll. AES ist eine symmetrische Blockchiffrierung, die Daten in mehreren Durchgängen verschlüsselt und entschlüsselt. Die Aktivierung dieser Funktion hat Leistungsverbesserungen in der SSL-Verarbeitung von WebSphere Application Server zur Folge.

  • [AIX Solaris HP-UX Linux Windows][z/OS]-Xquickstart
    Geben Sie -Xquickstart an, wenn die Erstkompilierung auf einer geringeren Optimierungsstufe als im Standardmodus stattfinden soll. Später können Sie die Kompilierung in Abhängigkeit von den Probeergebnissen auf der Optimierungsstufe im Standardmodus erneut durchführen.
    Bewährtes Verfahren Bewährtes Verfahren: Verwenden Sie -Xquickstart für Anwendungen, für die eine frühere angemessene Geschwindigkeit wichtiger ist als der langfristige Durchsatz. In einigen Debug-Szenarien, Testläufen und Tools mit kurzen Ausführungszeiten können Sie die Startzeit um 15 bis 20 % verkürzen.bprac
    Fehler vermeiden Fehler vermeiden: Dieses Argument wird unter IBM i nicht unterstützt.gotcha
  • [AIX Solaris HP-UX Linux Windows][z/OS]-Xverify:none

    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 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.
    • [IBM i]Dieses Argument wird unter IBM i nicht unterstützt.
    gotcha
  • [AIX Solaris HP-UX Linux Windows][z/OS]-Xnoclassgc

    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 Fehler vermeiden: Der Leistungseinfluss der Garbage-Collection ist im Normalfall minimal, und das Inaktivieren der Garbage-Collection für Klassen in einem auf Java EE (Java Platform, Enterprise Edition) basierenden System mit seiner umfangreichen Nutzung von Anwendungsklassenladern kann dazu führen, dass bei Klassendaten ein Speicherleck entsteht, und bewirken, dass die JVM eine Ausnahme aufgrund abnormaler Speicherbedingungen absetzt.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 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
  • [AIX Solaris HP-UX Linux Windows][z/OS]-Xgcthreads

    Geben Sie -Xgcthreads an, wenn Sie mehrere Garbage-Collection-Threads gleichzeitig verwenden möchten. Diese Garbage-Collection-Technik wird 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 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 fünf Prozessoren.

    gotcha
    Bewährtes Verfahren Bewährtes Verfahren: Sie müssen parallele Garbage-Collection verwenden, wenn Ihre Maschine mehrere Prozessoren hat.bprac
    Fehler vermeiden Fehler vermeiden: Dieses Argument wird unter IBM i nicht unterstützt.gotcha
  • [AIX Solaris HP-UX Linux Windows][z/OS]-Xnocompactgc

    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 Fehler vermeiden: Dieses Argument wird unter IBM i nicht unterstützt.gotcha
  • [AIX Solaris HP-UX Linux Windows][z/OS]-Xgcpolicy

    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 Concurrent Mark (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 balanced (ausgeglichen), wenn Sie die Garbage-Collection nach dem Mark-and-Sweep-Verfahren, nach dem Mark-and-Compact-Verfahren oder die Garbage-Collection nach dem Objektalter (Generationell) verwenden möchten. Die Concurrent-Mark-Phase ist inaktiviert. Die Technologie der Concurrent-Garbage-Collection (gleichzeitig ablaufende Garbage-Collection) wird zwar verwendet, aber nicht in der Art und Weise, in der Concurrent Mark für andere Richtlinien implementiert wird. Die Richtlinie für ausgeglichene Garbage Collection verwendet ein regionsbasiertes Layout für den Java™-Heapspeicher. Die Regionen werden einzeln verwaltet, um die maximale Pausezeit bei großen Heapspeichern zu verringern und die Effizienz der Garbage-Collection zu verbessern. Die Richtlinie versucht, globale Garbage-Collections zu vermeiden, indem Objektzuordnung und Überlebensrate miteinander abgeglichen werden. Wenn Sie Probleme mit Anwendungspausezeiten haben, die von der globalen Garbage-Collection verursacht werden, insbesondere von den Komprimierungen, kann diese Richtlinie die Anwendungsleistung verbessern. Bei Verwendung großer Systeme mit NUMA-Merkmalen (Non-Uniform Memory Architecture - gilt nur für x86- und POWER®-Plattformen), kann die Richtlinie für ausgeglichene Garbage-Collection ("balanced") den Anwendungsdurchsatz weiter verbessern.

    Fehler vermeiden Fehler vermeiden: Dieses Argument wird unter IBM i nicht unterstützt.gotcha
  • [AIX Solaris HP-UX Linux Windows][z/OS]-XX

    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 Pool die Dauer eines Garbage-Collection-Zyklus nicht überschreiten. Verwenden Sie die Parameter NewSize und MaxNewSize, um die Größe des neuen generationellen Pools festzulegen.

    Objekte, die den ersten Garbage-Collection-Zyklus "überleben", werden in einen anderen Pool übertragen. Verwenden Sie den Parameter SurvivorRatio, um die Größe des Survivor-Pools festzulegen. Sie können die von Tivoli Performance Viewer erfassten Objektstatistiken verwenden oder das Argument "verbose:gc" in Ihre Konfiguration aufnehmen, um die Garbage-Collection-Statistiken zu überwachen. Wenn die Garbage-Collection zu einem Engpass wird, geben Sie die folgenden Argumente an, um die Einstellungen für den generationellen Pool besser an Ihre Umgebung anzupassen.
    -XX:NewSize=unterer_Grenzwert
    -XX:MaxNewSize=oberer_Grenzwert
     -XX:SurvivorRatio=neues_Verhältnis 
    Die Standardwerte sind im Folgenden aufgelistet:
    • NewSize=2m
    • MaxNewSize=32m
    • SurvivorRatio=32
    Bewährtes Verfahren 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 generationellen Pool festlegen.

    Fehler vermeiden Fehler vermeiden: Dieses Argument wird unter IBM i nicht unterstützt.gotcha
  • [AIX Solaris HP-UX Linux Windows][z/OS]-Xminf

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

    Fehler vermeiden Fehler vermeiden: Dieses Argument wird unter IBM i nicht unterstützt.gotcha
  • [AIX Solaris HP-UX Linux Windows][z/OS]-server | -client

    Java HotSpot Technology in Java SE 6 verwendet eine adaptive JVM, die Algorithmen enthält, die die Leistung des Bytecodes mit der Zeit optimieren. 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 Fehler vermeiden: Dieses Argument wird unter IBM i nicht unterstützt.gotcha
  • -Dcom.ibm.CORBA.RequestTimeout=Zeitlimit

    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.

  • -Dcom.ibm.server.allow.sigkill=true

    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.

  • -Dcom.ibm.websphere.alarmthreadmonitor.hung_alarm_mute=

    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.

    Anmerkung: Diese Eigenschaft gibt einen Grenzwert für jede Alarmhandlerklasse und nicht für die Gesamtanzahl der Nachrichten bzw. für jede Alarmhandlerinstanz an.
  • -Dcom.ibm.websphere.native.logging.timestamp=true

    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
    Anmerkung: Verwenden Sie -Dws.ext.debug=true nur unter Anleitung des IBM Support.
  • -Dcom.ibm.ws.wim.registry.DbSharedAcrossMultipleServers=true

    Geben Sie -Dcom.ibm.ws.wim.registry.DbSharedAcrossMultipleServers=true an, wenn DB/LA-Repositorys des Virtual Member Manager (VMM) von verschiedenen Installationen gemeinsam genutzt werden. Diese Eigenschaft ist nicht für Clusterumgebungen vorgesehen. Wenn diese Eigenschaft festgelegt wird, kann der VMM Aufrufe von WebSphere Application Server-Installationen, die Repositorys gemeinsam nutzen, synchronisieren.

  • [z/OS]-Dcom.ibm.websphere.wlm.unusable.interval=Intervall

    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.

  • [z/OS]-Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl=

    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.

    Die direkten Bytepuffer, die die JVMs für die Bearbeitung von Anforderungsdaten erstellt, werden im Language Environment-Heapspeicher (LE) und nicht im JVM-Heapspeicher reserviert. Aber selbst wenn die direkten Bytepuffer nicht mehr benötigt werden, gibt die JVM diesen nativen LE-Speicher erst bei der nächsten Garbage-Collection frei. Wenn der Server große Anforderungen verarbeitet, kann der LE-Speicher bereits vor einem Garbage-Collection-Zyklus erschöpft sein, was dazu führt, dass der Server abnormal beendet wird (Abend). Die Konfiguration der JVM mit dem folgenden Argument verhindert das Auftreten dieser abnormalen Beendigungen.
    -Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl=com.ibm.ws.buffermgmt.impl.ZOSWsByteBufferPoolManagerImpl

    [z/OS]Auf der Plattform z/OS müssen Sie dieses Argument auch dann angeben, wenn Sie die angepasste Eigenschaft zaioFreeInitialBuffers für einen TCP-Kanal festlegen, damit der Kanal die anfänglichen Lesepuffer für neue Verbindungen freigibt, sobald sie für die Verbindung nicht mehr benötigt werden.

  • [z/OS]-DisSipComplianceEnabled=true|false

    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 Fehler vermeiden: Wenn Sie einen Proxy-Server in einer z/OS-Umgebung von 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 und 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
  • [AIX Solaris HP-UX Linux Windows][z/OS]-Xshareclasses:none

    Mit dem Argument -Xshareclasses:none können Sie die Option für gemeinsame Nutzung von Klassen für einen Prozess inaktivieren. 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 auf oder stoppen Sie den Prozess und starten Sie ihn anschließend erneut.

    Anmerkung: Wenn Sie clearClassCache verwenden, müssen Sie zum Löschen des gesamten Cache alle zugeordneten JVMs stoppen.
    Fehler vermeiden Fehler vermeiden:
    • In einem Anwendungsserverprozess ausgeführte Java EE-Anwendungsklassen werden dem Cache für gemeinsam genutzte Klassen nicht hinzugefügt.
    gotcha
  • -XXallowvmshutdown:false

    Verwenden Sie das Argument -XXallowvmshutdown:false, um die JVM, die nicht ordnungsgemäß ausgeführt wird, zu einem vorheriges Verhalten zurückzuversetzen. 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.

Information Wert
Datentyp String
Einheiten Java-Befehlszeilenargumente

Name der ausführbaren JAR-Datei

Gibt einen vollständigen Pfadnamen für eine ausführbare JAR-Datei an, die vom JVM-Code verwendet wird.

Information Wert
Datentyp String
Einheiten Pfadname

JIT inaktivieren

Gibt an, ob die JIT-Compileroption des JVM-Codes inaktiviert wird.

Wenn Sie den JIT-Compiler inaktivieren, nimmt der Durchsatz merklich ab. Im Hinblick auf den Durchsatz sollte JIT deshalb aktiviert bleiben.

Information Wert
Datentyp Boolean
Standardwert false (JIT aktiviert)
Empfohlene Einstellung JIT aktiviert

Name des Betriebssystems

Gibt die JVM-Einstellungen für ein bestimmtes Betriebssystem an.

Beim Prozessstart verwendet der Prozess die JVM-Einstellungen, die für den Knoten als JVM-Einstellungen für das Betriebssystem festgelegt wurden.


Symbol, das den Typ des Artikels anzeigt. Referenzartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=urun_rconfproc_jvm
Dateiname:urun_rconfproc_jvm.html