Verwenden Sie diese Seite, um die JVM-Konfigurationseinstellungen eines Prozesses für einen Anwendungsserver anzuzeigen und zu ändern.
Zum Anzeigen dieser Seite müssen Sie eine Verbindung zur Administrationskonsole herstellen und zur Anzeige "Java Virtual Machine" navigieren.
Für IBM i
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 JVM-Code 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 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, 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.
Gibt an, ob die Debug-Ausgabe für das Klassenladen im ausführlichen Modus erfolgen soll. Der Standardwert sieht vor, den ausführlichen Modus für das Klassenladen nicht zu aktivieren.
Wenn der ausführliche Modus für das Klassenladen aktiviert ist,
wird die Debug-Ausgabe an eines der nativen Prozessprotokolle gesendet.
Datentyp | Boolean |
Standardeinstellung | false |
Gibt an, ob die Debug-Ausgabe für die Garbage-Collection im ausführlichen Modus erfolgen soll. Der Standardwert sieht vor, den ausführlichen Modus für die Garbage-Collection nicht zu aktivieren.
Wenn der ausführliche Modus 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 Ihnen einen Überblick über die Funktionsweise des Java-Garbage-Collection-Prozesses.
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 wächst, sehen Sie sich den Prozentsatz des nicht zugeordneten Heap-Speichers nach jedem Garbage-Collection-Zyklus an, und vergewissern Sie sich, dass der Prozentsatz nicht weiter abnimmt. Wennn der Prozentsatz des freien Speicherbereichs weiter abnimmt, steigt die Heap-Speichergröße mit jeder Garbage-Collection allmählich an. Diese Situation kann auf Speicherverluste in Ihrer Anwendung hinweisen.
Auf der Plattform z/OS können Sie die Informationen zum JVM-Heap-Speicher
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 Java-Heap-Speichers steht auch der PMI
zur Verfügung und kann mit dem
Tivoli Performance Viewer überwacht werden.
Gibt an, ob die Debug-Ausgabe für den Aufruf nativer Methoden im ausführlichen Modus erfolgen soll. Standardmäßig wird der ausführliche Modus für JNI-Aktivitäten (Java Native Interface) nicht aktiviert.
Datentyp | Boolean |
Standardeinstellung | false |
Gibt die Anfangsgröße des Heap-Speichers (in MB) an, die dem JVM-Code zur Verfügung steht. Wenn dieses Feld leer bleibt, wird der Standardwert verwendet.
Unter z/OS ist der Standardwert für die Anfangsgröße des Heap-Speichers
48 MB für den Controller und 128 MB für den Servant. Diese Standardwerte gelten für
31-Bit- und 64-Bit-Konfigurationen.
Auf IBM i und verteilten Plattformen ist der Standardwert für die
Anfangsgröße des Heap-Speichers 50 MB.
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-Heap-Speichers, bis der Heap-Speicher zu groß für den physischen Speicher wird. Wenn die Größe des Heap-Speichers die Größe des verfügbaren physischen Hauptspeichers überschreitet und Paging stattfindet, nimmt die Leistung merklich ab.
Gibt die maximale Größe des Heap-Speichers (in MB) für den JVM-Code an. Wenn dieses Feld leer bleibt, wird der Standardwert verwendet.
Der Standardwert sind 256 MB. Dieser Standardwert gilt für 31-Bit- und 64-Bit-Konfigurationen.
Die Startzeit kann sich verkürzen, wenn Sie die Maximalgröße für den Heap-Speicher heraufsetzen. 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 Vergrößern dieser Einstellung, bis der Heap-Speicher zu groß für den physischen Speicher wird. Wenn die Größe des Heap-Speichers die Größe des verfügbaren physischen Hauptspeichers überschreitet und Paging stattfindet, nimmt die Leistung merklich ab. Deshalb ist es wichtig, die den Wert für diese Einstellung so zu definieren, 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 zu einem Leistungsabfall
führen.
Wenn diese Eigenschaft auf der Plattform IBM i auf 0 (null) gesetzt wird,
wird der Garbage-Collector nur ausgeführt, wenn der Schwellenwert für den Garbage-Collector erreicht ist.
Ist 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.
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.
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 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.
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.
Datentyp | Boolean |
Standardeinstellung | false |
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".
Wenn Sie das Debugging in mehreren Anwendungsservern, 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".
Datentyp | String |
Einheiten | Java-Befehlszeilenargumente |
Gibt die Befehlszeilenparameter 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, vielen Knoten und vielen Anwendungen enthalten.
Dieses Argument gilt nur für z/OS. 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.
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 liegt bei 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-Channel angeben, damit der Channel die anfänglichen Lesepuffer für neue Verbindungen
freigibt, sobald sie für die Verbindung nicht mehr benötigt werden.
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.
Sie können -Xverify:none verwenden, wenn Sie die Phase mit der Übeprü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, 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.
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.
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. Wenn beispielsweise 3 Prozessoren auf der Maschine ausgeführt werden, geben Sie -Xgcthreads 3 ein. Auf einem Knoten mit n Prozessoren ist die Standardanzahl an Threads gleich n.
Geben Sie -Xnocompactgc an, wenn Sie die Komprimierung des Heap-Speichers inaktivieren möchten. Die Komprimierung des Heap-Speichers ist die kostenintensivste Garbage-Collection-Operation. Wenn Sie IBM Developer Kit verwenden, müssen Sie die Komprimierung des Heap-Speichers vermeiden. Wenn Sie die Heap-Komprimierung inaktivieren, fällt der damit in Zusammenhang stehende Aufwand weg.
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. Dies ist der Standardparameter und die empfohlene Einstellung.
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 Heap-Speicher 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 Anwendungs-Threads zu überwachen, die aus dem Stack gestartet werden, bevor der Heap-Speicher 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 Heap-Speicher in Speicherteilbereiche unterteilt, die eine bessere Skalierbarkeit für die Objektzuordnung bieten.
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
Alternativ können Sie 50 % bis 60 % der Gesamtgröße des Heap-Speichers für einen neuen Generationspool festlegen.
Geben Sie -Xminf an, wenn Sie die Mindestgröße des freien Heap-Speichers in Prozent ändern möchten. 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).
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, 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 Sie stoppen den Prozess und starten ihn anschließend erneut.
Datentyp | String |
Einheiten | Java-Befehlszeilenargumente |
Gibt einen vollständigen Pfadnamen für eine ausführbare JAR-Datei an, die vom JVM-Code verwendet wird.
Datentyp | String |
Einheiten | Pfadname |
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.
Datentyp | Boolean |
Standardeinstellung | false (JIT aktiviert) |
Empfohlene Einstellung | JIT aktiviert |
Gibt die JVM-Einstellungen für ein bestimmtes Betriebssystem an.
Beim Prozessstart verwendet der Prozess die JVM-Einstellungen, die für den Server als JVM-Einstellungen für das Betriebssystem festgelegt wurden.
Beim Prozessstart verwendet der Prozess die JVM-Einstellungen, die für den Knoten als JVM-Einstellungen für das Betriebssystem festgelegt wurden.
Mit (online) gekennzeichnete Links setzen einen Internet-Zugang voraus.