IBM Virtual Machine for Java optimieren
Ein Anwendungsserver ist ein Java™-basierter Server und setzt eine JVM-Umgebung (Java Virtual Machine) voraus, die die Unternehmensanwendungen unterstützt, die darin ausgeführt werden. Im Rahmen der Konfiguration Ihres Anwendungsservers können Sie Java SE Runtime Environment für eine optimale Leistung und eine optimale Nutzung der Systemressourcen konfigurieren. Dieser Artikel bezieht sich auf IBM® Virtual Machine for Java.
Vorbereitende Schritte
- Bestimmen Sie den Typ der JVM, in der Ihr Anwendungsserver ausgeführt wird.
Setzen Sie dazu den Befehl java –fullversion im Verzeichnis Stammverzeichnis_des_Anwendungsservers/java/bin Ihre Anwendungsservers ab.
Als Reaktion auf diesen Befehl schreibt Java Informationen zur JVM, einschließlich der Informationen zum JVM-Provider, in das Fenster, in dem Sie den Befehl ausführen, z. B.:
java full version "JRE 1.6.0 IBM Windows 32 build pwi3260sr7-20091217_01 (SR7)"
Als Reaktion auf diesen Befehl schreibt Java Informationen zur JVM, einschließlich der Informationen zum JVM-Provider in die Standardfehlerausgabe (stderr).
Setzen Sie den Befehl "dspwasinst" im Verzeichnis "Profilstammverzeichnis/bin" ab. Die Ausgabe dieses Befehls enthält die Einstellung der Variablen JAVA_HOME und weitere Informationen zu der JVM, die für Ihr Anwendungsserverprofil aktiviert ist.
Wenn Ihr Anwendungsserver in eine rSun HotSpot JVM ausgeführt wird, lesen Sie den Artikel Sun HotSpot Java Virtual Machines optimieren (Solaris & HP-UX).
Verwenden Sie den Befehl "managesdk", wenn Sie Ihr Anwendungsserverprofil für die Verwendung einer anderen JVM aktivieren möchten.
Stellen Sie Folgendes sicher:
- Auf dem System ist die neueste unterstützte Version der JVM installiert.
- Auf dem System ist die aktuelle Funktionsaktualisierung installiert. Nahezu jedes neue Service-Level enthält JVM-Leistungsverbesserungen.
Auf dem System ist die aktuelle Funktionsaktualisierung installiert. Nahezu jedes neue Service-Level enthält JVM-Leistungsverbesserungen.
Informationen zu diesem Vorgang
Jeder JVM-Anbieter stellt detaillierte Informationen zur Leistung und Optimierung seiner JVM bereit. Verwenden Sie die Informationen in diesem Artikel zusammen mit den Informationen, die mit der JVM bereitgestellt werden, die auf Ihrem System ausgeführt wird.
Der Controller und der Servant enthalten jeweils eine eigene JVM. Die Informationen in diesem Artikel beziehen sich nur auf die JVM im Servant. Gewöhnlich muss die
JVM im Controller nicht optimiert werden.
Java SE Runtime Environment stellt die Umgebung für die Ausführung von Unternehmensanwendungen und Anwendungsservern bereit. Daher spielt die Java-Konfiguration beim Ermitteln der Leistung und Systemressourcennutzung für einen Anwendungsserver und die Anwendungen, die darunter ausgeführt werden, eine große Rolle.
IBM Virtual Machine for Java Version 6.0 umfasst die neuesten Java EE-Spezifikationen (Java Platform, Enterprise Edition) und bietet gegenüber früheren Java-Versionen eine verbesserte Leistung und Stabilität.
Obwohl die JVM-Optimierung vom verwendeten JVM-Provider abhängig ist, gibt es jedoch einige allgemeine Optimierungskonzepte, die für alle JVMs gelten. Einige dieser allgemeinen Konzepte sind im Folgenden aufgeführt:
- Compiler-Optimierung. Alle JVMs verwenden JIT-Compiler (Just-In-Time), um Java-Bytecodes zur Laufzeit des Servers in native Anweisungen zu kompilieren.
- Optimierung des Java-Haupt- oder -Heapspeichers. Die Optimierung der JVM-Speicherverwaltungsfunktionen oder der Garbage-Collection ist ein guter Ausgangspunkt für die Verbesserung der JVM-Leistung.
- Optimierung des Ladens von Klassen.
- Optimierung von Startleistung vs. Laufzeitleistung
Die folgenden Schritte enthalten spezifische Anweisungen dazu, wie Sie die angegebene Art der Optimierung für jede JVM ausführen können. Diese Schritte müssen nicht in einer bestimmten Reihenfolge ausgeführt werden.
Vorgehensweise
Beschränken Sie die Anzahl der Speicherauszüge, die in bestimmten Situationen erstellt werden.
Unter bestimmten Fehlerbedingungen können mehrere Anwendungsserverthreads fehlschlagen und die JVM fordert für jeden dieser Threads einen TDUMP an. Wenn sehr viele Threads gleichzeitig scheitern, kann die Anzahl der daraufhin gleichzeitig erstellten TDUMPs zu weiteren Systemproblemen führen, z. B. zu einer Knappheit des Zusatzspeichers. Mit der Umgebungsvariablen "JAVA_DUMP_OPTS" können Sie die Anzahl der Speicherauszüge angeben, die die JVM in bestimmten Situationen erstellen soll. Sie hat jedoch keine Auswirkung auf die Anzahl der generierten TDUMPS. Dies ist auf die Aufrufe von "com.ibm.jvm.Dump.SystemDump()" in Anwendungen, die im Anwendungsserver ausgeführt werden, zurückzuführen.
Beispiel: Sie möchten Ihre JVM wie folgt konfigurieren:- Die JVM soll die Anzahl der erstellten TDUMPs auf einen einzigen beschränken.
- Die JVM soll die Anzahl der zu erstellenden JAVADUMPs auf maximal 3 beschränken.
- Die JVM soll bei einem INTERRUPT keine Dokumentation erfassen.
In diesem Fall müssen Sie die Variable "JAVA_DUMP_OPTS" auf den folgenden Wert setzen:JAVA_DUMP_OPTS=ONANYSIGNAL(JAVADUMP[3],SYSDUMP[1]),ONINTERRUPT(NONE)
- Optimieren Sie die Start- und Laufzeitleistung.
In einigen Umgebung ist es wichtiger, die Startleistung Ihres Anwendungsservers anstatt die Laufzeitleistung zu optimieren. In anderen Umgebungen ist das genaue Gegenteil der Fall. Standardmäßig ist die Optimierung von IBM Virtual Machine for Java auf die Laufzeitleistung ausgerichtet, während die HotSpot-basierten JVMs für die Startleistung optimiert werden.
Der Java-JIT-Compiler hat einen großen Einfluss auf die Optimierung der Start- und Laufzeitleistung. Die vom Compiler verwendete Optimierungsstufe für die Erstkompilierung wirkt sich auf die erforderliche Zeit für die Kompilierung einer Klassenmethode und auf die erforderliche Zeit für das Starten des Servers aus. Für eine schnellere Startprozedur sollten Sie die Optimierungsstufe, die der Compiler für die Erstkompilierung verwendet, herabsetzen. Dies hat möglicherweise zur Folge, dass die Laufzeitleistung Ihrer Anwendungen abnimmt, weil die Klassenmethoden jetzt auf einer niedrigeren Optimierungsstufe kompiliert werden.
- -Xquickstart
Diese Einstellung bewirkt, dass IBM Virtual Machine for Java eine niedrigere Optimierungsstufe für die Kompilierung der Klassenmethoden verwendet. Eine niedrigere Optimierungsstufe erzielt schnellere Startzeiten für den Server, hat aber eine Verschlechterung der Laufzeitleistung zur Folge. Wenn dieser Parameter nicht angegeben wird, verwendet IBM Virtual Machine for Java standardmäßig eine hohe Optimierungsstufe für die Erstkompilierung, die eine höher Laufzeitleistung, aber eine geringere Startleistung des Servers zur Folge hat.
Sie können diese Eigenschaft in der Anzeige "Java Virtual Machine" in der Administrationskonsole definieren. Weitere Einzelheiten finden Sie in den Informationen zu den JVM-Einstellungen.
Information Wert Standardwert Hohe Optimierungsstufe des Compilers für Erstkompilierung Empfohlene Einstellung Hohe Optimierungsstufe des Compilers für Erstkompilierung Syntax Durch die Angabe von -Xquickstart kann die Startzeit des Servers verbessert werden.
Zur Beschleunigung der JVM-Initialisierung und des Serverstarts geben Sie auf der Registerkarte "Konfiguration" im Abschnitt "Allgemeine Eigenschaften" unter Allgemeine JVM-Argumente die folgenden Befehlszeilenargumente ein:
-Xquickstart -Xverify:none
- -Xquickstart
- Konfigurieren Sie die Größe des Heapspeichers.
Die Parameter für den Java-Heapspeicher wirken sich auf das Verhalten der Garbage-Collection aus. Wenn der Heapspeicher vergrößert wird, können mehr Objekte erstellt werden. Da es länger dauert, bis ein großer Heapspeicher gefüllt ist, läuft die Anwendung länger, bis die nächste Garbage-Collection stattfindet. Es dauert aber auch länger, den größeren Heapspeicher zu komprimieren, sodass die Garbage-Collection mehr Zeit beansprucht.
Die JVM verwendet definierte Schwellenwerte, um den zugeordneten Speicher zu verwalten. Sind die Schwellenwerte erreicht, wird der Garbage-Collector aufgerufen, um nicht verwendeten Speicher freizugeben. Die Garbage-Collection kann zu einem deutlichen Rückgang des Java-Durchsatzes führen. Berücksichtigen Sie die folgenden Informationen, bevor Sie die Anfangsgröße und die maximale Größe des Heapspeichers ändern:- In der Mehrzahl der Fälle sollten Sie die maximale Heapspeichergröße auf einen höheren Wert als die Anfangsgröße des Heapspeichers setzen. Mit einer solchen Einstellung kann die JVM in Perioden mit normalen und konstanten Auslastungsbedingungen innerhalb der Grenzen der Anfangsgröße des Heapspeichers, aber auch in Perioden mit hohem Transaktionsaufkommen effizient arbeiten, indem der Heapspeicher auf seine maximale Größe ausgedehnt wird. In einigen selten Fällen, in denen eine optimale Leistung erforderlich ist, können Sie für die Anfangsgröße und die maximale Größe des Heapspeichers denselben Wert festlegen. Bei dieser Einstellung entfällt der Aufwand, der anfällt, wenn die JVM den JVM-Heapspeicher vergrößert oder verkleinert. Stellen Sie vor dem Ändern der Größenparameter für den JVM-Heapspeicher sicher, dass der zugeornete JVM-Speicher für die neue Größe des Heapspeichers ausreicht.
- Wählen Sie als Anfangsgröße für den Heapspeicher keinen Wert aus, der so groß ist, dass er zwar zunächst die Leistung verbessert, indem er die Garbage-Collection verzögert, aber bei der Garbage-Collection dann dafür sorgt, dass sich der Erfassungsprozess auf die Antwortzeit auswirkt, weil der Prozess länger ausgeführt wird.
Informationen zum Java-Heapspeicher sind in den SMF-Datensätzen enthalten. Diese Informationen können dynamisch mit dem Konsolbefehle DISPLAY,JVMHEAP angezeigt werden.
Gehen Sie wie folgt vor, um die Größe des Heapspeichers in der Administrationskonsole zu konfigurieren:
- Klicken Sie in der Administrationskonsole auf Server>Servertypen>WebSphere-Anwendungsserver> Servername.
Klicken Sie im Abschnitt "Serverinfrastruktur" auf Java- und Prozessverwaltung > Prozessdefinition > Java Virtual Machine.
Klicken Sie im Abschnitt "Serverinfrastruktur" auf Java- und Prozessverwaltung > Prozessdefinition.
Wählen Sie Steuerung oder Servant aus und wählen Sie anschließend Java Virtual Machine aus.
- Geben Sie im Feld Anfangsgröße des Heapspeichers oder im Feld Maximale Größe des Heapspeichers einen neuen Wert an.
Sie können auch Werte für beide Felder angeben, falls beide Einstellungen angepasst werden müssen.
Für die Leistungsanalyse müssen die Anfangsgröße und maximale Größe des Heapspeichers identisch sein.
Die Einstellung für die Anfangsgröße des Heapspeichers (in MB) gibt die Speicherkapazität an, die für die JVM beim Start der JVM zugeordnet wird. Die Einstellung für die maximale Größe des Heapspeichers (in MB) gibt die maximale Speicherkapazität an, die dem JVM-Heapspeicher zugeordnet werden kann. Beide Einstellung haben erhebliche Auswirkungen auf die Leistung.
Wenn Sie ein Produktionssystem optimieren möchten und Ihnen die Arbeitsspeichergröße der Unternehmensanwendungen, die auf diesem System ausgeführt werden, nicht bekannt ist, sollten Sie die Anfangsgröße des Heapspeichers zunächst auf 25 % der maximalen Größe des Heapspeichers setzen. Die JVM versucht daraufhin, die Größe des Heapspeichers an die Arbeitsspeichergröße der Anwendung anzupassen.
Die folgende Abbildung zeigt drei CPU-Profile mit jeweils fest definierter Arbeitsbelastung und verschiedenen Java-Heapspeichereinstellungen. Im mittleren Profil sind die Anfangsgröße des Heapspeichers und die maximale Größe des Heapspeichers auf je 128 MB gesetzt. Es werden vier Garbage-Collections durchgeführt. Die Zeit für diese Garbage-Collections beträgt ca. 15 % der Gesamtausführungszeit. Wenn die Heapparameter wie im oberen Profil auf 256 MB verdoppelt werden, nimmt die Verarbeitungszeit zwischen den Garbage-Collections zu. Es finden nur drei Garbage-Collections statt. Jede dieser Garbage-Collections dauert allerdings länger. Im dritten Profil ist die Größe des Heapspeichers auf 64 MB reduziert, was zum gegenteiligen Effekt führt. Bei kleinerem Heapspeicher sinkt die Zeit zwischen den Garbage-Collections und die für jede einzelne Garbage-Collection benötigte Zeit. Bei allen drei Konfigurationen liegt die insgesamt für Garbage-Collections benötigte Zeit bei ungefähr 15 %. Dieses Beispiel illustriert ein wichtiges Konzept des Java-Heapspeichers und seines Verhältnisses zur Objektnutzung. Es entsteht immer Aufwand für die Garbage-Collection, wenn Unternehmensanwendungen ausgeführt werden.
Führen Sie eine Reihe von Tests mit unterschiedlichen Einstellungen für den Java-Heapspeicher durch. Führen Sie beispielsweise Tests mit 128 MB, 192 MB, 256 MB und 320 MB aus. Überwachen Sie bei jedem Test die Gesamtspeicherauslastung. Wenn Sie den Heapspeicher zu stark ausweiten, können Seitenwechsel auftreten.
Verwenden Sie den Befehl vmstat oder den Systemmonitor von Windows, um die Seitenauslagerung (Paging) zu überprüfen. Liegen Seitenauslagerungen vor, sollten Sie den Heapspeicher verkleinern oder die Speicherkapazität des Systems erhöhen.
Verwenden Sie den IBM i-Befehl WRKSYSSTS, um das Paging zu überprüfen. Liegen Seitenauslagerungen vor, sollten Sie den Heapspeicher verkleinern oder die Speicherkapazität des Systems erhöhen.
Liegen Seitenauslagerungen vor, sollten Sie den Heapspeicher verkleinern oder die Speicherkapazität des Systems erhöhen.
Vergleichen Sie nach Abschluss aller Durchläufe die folgenden Statistiken:- Die Anzahl der Garbage-Collection-Aufrufe.
- Die durchschnittliche Dauer eines Garbage-Collection-Aufrufs.
- Das Verhältnis zwischen der Dauer eines Garbage-Collection-Aufrufs und dem Intervall zwischen zwei Aufrufen.
Wenn die Anwendung keine Objekte überlastet und keine Speicherverluste auftreten, ist der Zustand einer stabilen Speicherbelegung erreicht. Die Garbage-Collections werden seltener durchgeführt und sind kürzer.
Wenn der Heapspeicher 85 % der Zeit oder länger nicht genutzt wird, sollten Sie eine Verringerung der maximalen Größe des Heapspeichers in Erwägung ziehen, da der Anwendungsserver und die Anwendung den zugeordneten Heapspeicher nicht auslasten können.
Wenn Sie Server für die Ausführung im 64-Bit-Modus konfiguriert haben, können Sie eine maximale Größe für den JVM-Heapspeicher für diese Server festlegen, die erheblich höher ist als die Standardeinstellunge. Sie können beispielsweise eine maximale Anfangsgröße für den Heapspeicher von 1844 MB für den Controller und den Servant angeben, wenn der Server für die Ausführung im 64-Bit-Modus konfiguriert ist.
- Klicken Sie auf Anwenden.
- Klicken Sie auf Speichern, um Ihre Änderungen in der Masterkonfiguration zu speichern.
- Stoppen Sie den Anwendungsserver und starten Sie ihn dann erneut.
Die können diese Einstellungen auch mit folgenden Befehlszeilenparametern anpassen. Diese Parameter gelten für alle unterstützten JVMs. Sie werden verwendet, um die Mindestgröße und die maximale Größe des Heapspeichers für jeden Anwendungsserver und Anwendungsserverinstanz anzupassen.
- -Xms
Dieser Parameter steuert die Anfangsgröße des Java-Heapspeichers. Durch eine angemessene Einstellung dieses Parameters können Sie den Aufwand für die Garbage-Collection reduzieren und damit Antwortzeit und Durchsatz des Servers verbessern. Für einige Anwendungen kann die Standardeinstellung für diese Option zu niedrig sein. Dies hat zur Folge, dass viele kleine Garbage-Collections durchgeführt werden.
Information Wert Standardwert 50 MB Empfohlene Einstellung Arbeitslastspezifisch, aber höher als die Standardeinstellung Syntax -Xms256m legt die Anfangsgröße für den Heapspeicher mit 256 MB fest. - -Xmx
Dieser Parameter steuert die maximale Größe des Java-Heapspeichers. Eine höhere Einstellung für diesen Parameter hat zur Folge, dass der für den Anwendungsserver verfügbare Speicher erhöht und die Häufigkeit der Garbage-Collections reduziert wird. Daher kann eine höhere Einstellung die Antwortzeit und den Durchsatz des Servers verbessern. Allerdings hat dies auch zur Folge, dass die Garbage-Collection, wenn sie stattfindet, mehr Zeit benötigt. Diese Einstellung sollte niemals höher sein als der für die Anwendungsserverinstanzen verfügbare Systemspeicher. Wird eine höhere Einstellung verwendet als der verfügbare Systemspeicher, kann dies System-Paging und einen signifikanten Leistungsabfall zur Folge haben.
Information Wert Standardwert Standardmäßig berechnet die JVM die Größe des Java-Heapspeicher basierend auf dem im System verfügbaren Speicher. Empfohlene Einstellung Arbeitslastspezifisch, aber höher als die Standardeinstellung, je nach Menge des verfügbaren physischen Hauptspeichers. Syntax -Xmx512m legt die maximale Größe für den Heapspeicher mit 512 MB fest. Fehler vermeiden: Geben Sie einen Wert für den Parameter -Xmx an, um Probleme aufgrund abnormaler Speicherbedingungen möglichst zu vermeiden.gotcha
-Xlp
Verwenden Sie diesen Parameter mit der IBM Virtual Machine for Java, um den Heapspeicher bei der Verwendung großer Seiten, z. B. Seiten mit 16 MB, zuzuordnen. Stellen Sie vor der Definition dieses Parameters sicher, dass Ihr Betriebssystem für die Unterstützung großer Seiten konfiguriert ist. Durch die Verwendung großer Seiten kann die erforderliche CPU-Zeit für die Überwachung des Heapspeichers reduziert werden. Möglicherweise kann sogar ein größerer Heapspeicher erstellt werden.
Standardwert 64 KB bei Verwendung von Java 8 –Xlp64k
Dieser Parameter kann verwendet werden, um den Heapspeicher für Seiten mittlerer Größe, z. B. Seiten mit 64 KB, zuzuordnen. Die Verwendung dieser virtuellen Speicherseitengröße für den Speicher, den eine Anwendung benötigt, kann die Leistung und den Durchsatz der Anwendung aufgrund der Hardwareeffizienz, die sich durch Verwendung größerer Seitengrößen ergibt, verbessern.
i5/OS und AIX stellen eine umfassende Unterstützung für 64-KB-Seiten bereit, da 64-KB-Seiten als allgemein üblich betrachtet werden. 64-KB-Seiten lassen sich problemlos aktivieren und Anwendungen können Leistungsgewinne erzielen, wenn 64-KB-Seiten verwendet werden. Diese Einstellung kann geändert werden, ohne die Betriebssystemkonfiguration zu ändern. Es wird jedoch empfohlen, die Anwendungsserver in einem separaten Speicherpool auszuführen, wenn Sie 64-KB-Seiten verwenden.
Empfohlene Einstellung Verwenden Sie, sofern möglich, eine Seitengröße von 64 KB. Systeme des Typs i5/OS POWER5+ und i5/OS Version 6, Release 1 unterstützen eine Seitengröße von 64 KB.
POWER5+-Systeme und AIX 5L Version 5.3 mit 5300-04 Recommended Maintenance Package unterstützen eine Seitengröße von 64 KB, wenn sie mit dem 64-Bit-Kernel arbeiten.
–Xlp4k
Dieser Parameter kann verwendet werden, um den Heapspeicher mit 4-KB-Seiten zuzuordnen. Die Verwendung dieser virtuellen Speicherseitengröße anstelle der Seitengröße 64 KB für den Speicher, den eine Anwendung benötigt, kann die Leistung und den Durchsatz der Anwendung aufgrund der Hardwareeffizienz, die sich durch Verwendung kleinerer Seitengrößen ergibt, beeinträchtigen.
Die Einstellung für die Zuordnung des Java-Heapspeichers kann geändert werden, ohne die Betriebssystemkonfiguration zu ändern. Es wird jedoch empfohlen, die Anwendungsserver in einem separaten Speicherpool auszuführen, wenn Sie 64-KB-Seiten verwenden.
Empfohlene Einstellung Verwenden Sie -Xlp64k anstelle von -Xlp4k, sofern möglich.
- Optimieren Sie den Java-Speicher. Unternehmensanwendungen, die in Java geschrieben sind, beinhalten häufig komplexe Objektbeziehungen und verwenden eine große Anzahl von Objekten. Obwohl Java den Speicher, der einem Objekt für die Dauer seiner Gültigkeit zugeordnet ist, automatisch verwaltet, ist es wichtig, dass Sie die Objektverwendungsmuster der Anwendung kennen. Sie müssen insbesondere Folgendes sicherstellen:
- Die Anwendung überlastet keine Objekte.
- Die Anwendung verliert keine Objekte.
- Die Parameter für den Java-Heapspeicher sind so eingestellt, dass ein bestimmtes Muster für die Objektverwendung bearbeiten können.
- Prüfen Sie, ob eine übermäßige Verwendung der Objekte festzustellen ist.
Anhand der Zähler für die JVM-Laufzeitumgebung, die in Berichten von Tivoli Performance Viewer eingeschlossen sind, können Sie feststellen, ob eine Anwendung Objekte überlastet. Sie müssen die Befehlszeilenoption -XrunpmiJvmtiProfiler und die neueste Version des JVM-Moduls verwenden, um die JVMTI-Zähler (Java Virtual Machine Profiler Interface) zu aktivieren.
Das beste Ergebnis für die durchschnittliche Zeit zwischen Garbage-Collection-Durchläufen wird mit mindestens fünf- bis sechsfachen Zeit eines einzelnen Garbage-Collection-Durchlaufs erzielt. Andernfalls wendet die Anwendung mehr als 15 % der Ausführungszeit für die Garbage-Collection auf.
Sie können prüfen, ob die Anwendung Objekte überlastet. Beobachten Sie hierfür die Zähler für die JVM-Laufzeit. Sie müssen die Befehlszeilenoption -XrunpmiJvmtiProfiler und die neueste Version des JVM-Moduls verwenden, um die JVMTI-Zähler (Java Virtual Machine Profiler Interface) zu aktivieren. Das beste Ergebnis für die durchschnittliche Zeit zwischen Garbage-Collection-Durchläufen wird mit mindestens fünf- bis sechsfachen Zeit eines einzelnen Garbage-Collection-Durchlaufs erzielt. Andernfalls wendet die Anwendung mehr als 15 % der Ausführungszeit für die Garbage-Collection auf.
Sollten die Daten darauf hinweisen, dass die Garbage-Collection einen Engpass darstellt, gibt es zwei Möglichkeiten, diesen Engpass zu beseitigen. Am effektivsten ist es, die Anwendung durch das Implementieren von Objekt-Caches und -Pools zu optimieren. Stellen Sie mit einem Java Profiler fest, welche Objekte in Frage kommen. Sollte die Anwendung nicht optimiert werden können, bietet das Hinzufügen von Speicher, Prozessoren und Klonen Abhilfe. Zusätzlicher Speicher ermöglicht für jeden Klon eine vernünftige Heapspeichergröße. Zusätzliche Prozessoren sorgen dafür, dass die Klone parallel ausgeführt werden können.
- Prüfen Sie, ob Speicherverluste auftreten.
Speicherverluste in Java tragen in hohem Maße dazu bei, dass die Garbage-Collection zu einem Engpass wird. Sie sind gefährlicher als eine Speicherüberlastung, da sie unvermeidlich zu einer Instabilität des Systems führen. Mit der Zeit wird die Garbage-Collection häufiger durchgeführt, bis der Heapspeicher erschöpft ist und Fehler wegen fataler abnormaler Speicherbedingungen im Java-Code auftreten. Speicherverluste treten auf, wenn ein nicht verwendetes Objekt Referenzen enthält, die nie freigegeben werden. Speicherverluste treten am häufigsten in Collection-Klassen auf, z. B. in Hash-Tabellen, weil die Tabelle selbst immer eine Referenz auf das Objekt enthält, auch wenn alle realen Referenzen gelöscht wurden.
Bei starker Arbeitsbelastung geschieht es häufig, dass viele Anwendungen unmittelbar nach ihrem Deployment in der Produktionsumgebung abstürzen. Wenn in einer Anwendung Speicherverluste auftreten, kann eine hohe Arbeitslast die Verlustzunahme beschleunigen und zu Speicherzuordnungsfehlern führen.
Ziel des Tests auf Speicherverluste ist es, diese Verluste in ihrer Größenordnung deutlich vom nicht nutzbaren Speicher und vom genutzten Speicher abzugrenzen. Speicherverluste bewegen sich in der Größenordnung von Bytes oder Kilobytes, die von der Garbage-Collection nicht erfasst werden können. Die knifflige Aufgabe besteht darin, diese geringfügigen Verluste von der erwarteten Größe des nutzbaren und des nicht nutzbaren Speichers abzugrenzen. Zur Vereinfachung dieser Aufgabe wird mit größeren Zahlen gearbeitet, sodass die Differenzen größer erscheinen und Inkonsistenzen leicht festgestellt werden können. Die folgende Liste gibt Aufschluss darüber, wie die Ergebnisse von Speicherverlusttests interpretiert werden:- Langzeittest
Speicherverluste wirken sich erst nach einer gewissen Zeit aus und können deshalb nur in Langzeittests mit Sicherheit festgestellt werden. Kurzzeittest liefern unter Umständen ungültige Hinweise auf den Verursacher von Speicherverlusten. Es ist in der Programmiersprache Java manchmal schwer zu bestimmen, ob ein Speicherverlust auftritt, wenn sich die Speicherauslastung abrupt erhöht oder über einen bestimmten Zeitraum langsam ansteigt. Diese Art von wachsendem Speicherbedarf kann möglicherweise beabsichtigt oder vom Entwickler so gewollt sein. Aus diesem Grund ist es schwierig, einen Speicherverlust zu erkennen. Wie lassen sich aber verzögert verwendete Objekte von gar nicht verwendeten Objekten unterscheiden? Wenn Sie Anwendungen lange genug ausführen, können Sie mit größerer Sicherheit sagen, ob ein Objekt verzögert verwendet wird.
- Testwiederholungen
In vielen Fällen werden Speicherverluste offenbar, wenn dasselbe Anwendungsbeispiel mehrfach wiederholt wird. Ziel des Tests auf Speicherverluste ist es, diese Verluste in ihrer Größenordnung deutlich vom nicht nutzbaren Speicher und vom genutzten Speicher abzugrenzen. Durch die mehrfache Wiederholung desselben Testszenarien wird diese Unterscheidung zunehmend leichter. Eine solche Testdurchführung ist hilfreich, wenn der bei Ausführung eines Anwendungsbeispiels auftretende Speicherverlust so geringfügig ist, dass er in einem Durchlauf kaum festgestellt werden kann.
Wiederholte Tests können auf Systemebene oder Modulebene durchgeführt werden. Tests auf Modulebene bieten den Vorteil, dass sie besser gesteuert werden können. Wenn ein Test so ausgelegt ist, dass er sich auf ein reines Modul beschränkt, ohne externe Nebeneffekte wie eine Speichernutzung zu erzeugen, lassen sich Speicherverluste viel leichter erkennen. Zunächst wird die Speicherbelegung vor Ausführung des Moduls erfasst. Anschließend wird eine fest definierte Gruppe von Anwendungsbeispielen wiederholt ausgeführt. Am Ende des Testdurchlaufs wird die aktuelle Speicherbelegung erfasst und auf deutliche Änderungen überprüft. Vergessen Sie nicht, dass eine Garbage-Collection erzwungen werden muss, wenn Sie die aktuelle Speicherbelegung erfassen. Fügen Sie dazu System.gc() in das Modul ein, in dem die Garbage-Collection stattfinden soll. Sie können die Garbage-Collection auch mit einem Profiling-Tool erzwingen.
- Parallelitätstest
Manchmal treten Speicherprobleme nur auf, wenn in der Anwendung mehrere Threads aktiv sind. Synchronisationspunkte sind durch die höhere Komplexität der Programmlogik Schwachstellen, die schnell Speicherverluste verursachen können. Nachlässiges Programmieren kann zur Folge haben, dass Referenzen erhalten bleiben oder nicht freigegeben werden. Speicherverluste werden oft durch einer Zunahme der Parallelität begünstigt oder beschleunigt. Eine Zunahme der Parallelität können Sie in erster Linie durch eine Erhöhung der Anzahl Clients im Testtreiber erreichen.
Bedenken Sie die folgenden Punkte, wenn Sie sich für eines der Anwendungsbeispiele für den Test auf Speicherverluste entscheiden:- Ein gutes Anwendungsbeispiel bezieht Bereiche der Anwendung ein, in denen Objekte erstellt werden. Grundsätzlich sind überwiegend fundierte Kenntnisse zur Anwendung erforderlich. Die Beschreibung des Anwendungsbeispiels könnte das Erstellen von Datenräumen vorschlagen, z. B. das Hinzufügen eines neuen Datensatzes, das Erstellen einer HTTP-Sitzung, das Durchführen einer Transaktion und das Suchen nach einem Datensatz.
- Achten Sie auf Bereiche, in denen Objektgruppen verwendet werden. Speicherverluste treten in der Regel auf, wenn Objekte derselben Klasse kombiniert werden. Darüber hinaus sind Collection-Klassen wie Vektor- und Hash-Tabellen als Positionen bekannt, an denen Referenzen auf Objekte durch das Aufrufen der entsprechenden Einfügemethoden implizit gespeichert werden. Die Methode get eines Hash-Tabellenobjekts entfernt beispielsweise nicht ihren Verweis auf das angeforderte Objekt.
Sie können Tivoli Performance Viewer für die Erkennung von Speicherverlusten verwenden.
Die besten Ergebnisse erzielen Sie, wenn Sie Ihre Experimente wiederholen und jeweils die Dauer erhöhen, z. B. die Anzahl der Seitenanforderungen auf 1000, 2000 und 4000 erhöhen. Die Kurve, die der Tivoli Performance Viewer für die Speicherbelegung erstellt, sollte eine Sägezahnkurve sein. Jeder Abfall der Kurve markiert eine Garbage-Collection. In folgenden Fällen liegt ein Speicherverlust vor:
- Die Speicherbelegung nimmt nach jeder Garbage-Collection sprunghaft zu. In diesem Fall hat die Sägezahnkurve eher eine Wellenform, die wie eine Treppe aussieht.
- Das Muster der Sägezahnkurve ist unregelmäßig.
- Der Abstand zwischen der Anzahl zugeordneter und der Anzahl freigegebener Objekte nimmt mit der Zeit zu.
Die Erschöpfung des Heapspeichers bei einer kontinuierlichen CPU-Auslastung des Anwendungsservers von nahezu 100 % könnte auf einen Speicherverlust hinweisen. Wenn sich der Heapspeicherengpass bei einer folgenden geringfügigen Arbeitsbelastung (an der Grenze zum Leerlauf) jedoch auflöst, ist dies ein Indiz für eine Fragmentierung des Heapspeichers. Zu einer Fragmentierung des Heapspeichers kann es kommen, wenn die JVM während der Garbage-Collection-Zyklen genug Objekte für Speicherzuordnungsanforderungen freigeben kann, jedoch nicht dazu kommt, kleine freie Heapspeicherbereiche zu größeren zusammenhängenden Bereichen zusammenzuschieben.
Eine andere Form der Heapfragmentierung tritt auf, wenn Objekte mit weniger als 512 Bytes freigegeben werden. Die Objekte werden zwar freigegeben, der Speicher wird jedoch nicht wiederhergestellt, sodass es erst dann zu einer Fragmentierung kommt, wenn eine Komprimierung des Heapspeichers durchgeführt wird.
Die Fragmentierung des Heapspeichers kann durch das Erzwingen von Komprimierungen reduziert werden. Allerdings müssen Sie dafür Leistungseinbußen in Kauf nehmen. Verwenden Sie den Java-Befehl -X, um die Liste der Speicheroptionen anzuzeigen.
- Langzeittest
- Optimieren Sie die Garbage-Collection.
Die Java Virtual Machine (JVM) verwendet einen parallelisierten Garbage-Collector, um SMP während den meisten Garbage-Collection-Durchläufen maximal auszunutzen.
Eine eingehende Beschäftigung mit der Java-Garbage-Collection gibt einen Einblick in die Art und Weise, in der die Anwendung den Speicher nutzt. Die Garbage-Collection ist ein Vorzug, den Java bietet. Der Programmierer der Anwendung muss sich nicht um die Speicherverwaltung kümmern, so dass Java-Anwendungen in der Regel zuverlässiger als Anwendungen sind, die in Programmiersprachen ohne Unterstützung für die Garbage-Collection geschrieben wurden. Diese Zuverlässigkeit ist gewährleistet, solange die Anwendung keine Objekte überlastet. Die Garbage-Collection nimmt ungefähr 5 bis 20 % der gesamten Ausführungszeit einer fehlerfrei funktionierenden Anwendung in Anspruch. Ohne Verwaltung kann die Garbage-Collection zu einem der größten Engpässe für Anwendungen werden.
Die Überwachung der Garbage-Collection bei einer festen Workload gibt Ihnen Aufschluss darüber, ob die Anwendung Objekte überlastet. Mit Hilfe der Garbage-Collection können Sie sogar Speicherverluste feststellen.
Sie können die Art und das Verhalten der Garbage-Collection mithilfe von JVM-Einstellungen konfigurieren. Wenn die JVM nicht in der Lage ist, ein Objekt aus dem aktuellen Heapspeicher zuzuordnen, weil nicht genügend zusammenhängender Speicher vorhanden ist, wird der Garbage-Collector aufgerufen, um Speicher freizugeben, der von Java-Objekten belegt wird, die nicht mehr verwendet werden. Jeder JVM-Anbieter stellt spezielle Garbage-Collector-Strategien und Anpassungsparameter bereit.
Sie können die Einstellung Ausführliche Garbage-Collection in der Administrationskonsole verwenden, um die Überwachung der Garbage-Collection zu aktivieren. Die Ausgabe, die mit dieser Einstellung erreicht wird, enthält Klassenstatistiken für die Garbage-Collection. Das Format des generierten Berichts ist nicht standardisiert und kann in den verschiedenen JVMs oder Release-Levels variieren.
Gehen Sie wie folgt vor, um Ihre Garbage-Collection-Einstellungen für die JVM anzupassen:
- Klicken Sie in der Administrationskonsole auf Server>Servertypen>WebSphere-Anwendungsserver> Servername.
Klicken Sie im Abschnitt "Serverinfrastruktur" auf Java- und Prozessverwaltung > Prozessdefinition > Java Virtual Machine.
Geben Sie im Feld Generische JVM-Argumente die –X-Option ein, die Sie ändern möchten.
Klicken Sie im Abschnitt "Serverinfrastruktur" auf Java- und Prozessverwaltung > Prozessdefinition > Servant.
Klicken Sie unter "Weitere Eigenschaften" auf Umgebungseinträge.
Gehen Sie wie folgt vor, um den Umgebungseintrag für IBM_JAVA_OPTIONS hinzuzufügen oder zu aktualisieren.
- Wenn ein Umgebungseintrag mit dem Namen IBM_JAVA_OPTIONS vorhanden ist, editieren Sie den Eintrag und hängen Sie die Java-Option –X an den vorhandenen Wert an.
- Ist das nicht der Fall, klicken Sie auf Neu, um einen neuen Umgebungseintrag zu erstellen.
Tragen Sie die folgenden Werte in den entsprechenden Feldern des Formulars ein:
Information Wert Name: IBM_JAVA_OPTIONS Wert: Die Java-Option –X, die Sie hinzufügen möchten. Beschreibung: Eine Beschreibung dieser Option.
Mit dieser Prozedur wird die Datei was.env im Konfigurationsverzeichnis von WebSphereApplication Server aktualisiert. Durch die Änderung werden die Einstellungen auf alle Servant-Regionen, Steuerregionen und zusätzlichen Regionen angewendet.
- Klicken Sie auf Anwenden.
- Klicken Sie auf Speichern, um Ihre Änderungen in der Masterkonfiguration zu speichern.
- Stoppen Sie den Anwendungsserver und starten Sie ihn dann erneut.
In der folgenden Liste sind die –X-Optionen für die verschiedenen JVM-Garbage-Collector beschrieben.
- Garbage-Collector von IBM Virtual Machine for Java
- Eine ausführliche Dokumentation der
IBM Implementierung des Java-Garbage-Collectors enthält die Veröffentlichung IBM SDK, Java Technology Edition, Version 8 User Guide.
Verwenden Sie die Java-Option -X, um eine Liste der Speicheroptionen anzuzeigen.
- -XgcpolicyIBM Virtual Machine for Java stellt vier Strategien für die Garbage-Collection bereit. Jede Strategie hat spezielle Vorteile.Anmerkung: Zwar hat jede Richtlinie eindeutige Vorteile, für WebSphere Application Server Version 8 ist jedoch "gencon" die Standardrichtlinie für Garbage-Collection. Geben Sie in früheren Versionen des Anwendungsservers optthruput als Standardrichtlinie für die Garbage-Collection an.
- gencon ist die Standardrichtlinie. Die Richtlinie arbeitet mit dem Garbage-Collector, der auf dem Objektalter basiert. Mit Hilfe des Generationenprinzips 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.
- optthruput bietet einen hohen Durchsatz bei längeren Wartezeiten während der Garbage-Collection. Während einer Garbage-Collection werden alle Anwendungsthreads zwecks Markierung, Bereinigung und Komprimierung (falls eine Komprimierung erforderlich ist) gestoppt. Die Richtlinie "gencon" ist für die meisten Anwendungen ausreichend.
- Die Richtlinie "optavgpause" reduziert die Wartezeiten während der Garbage-Collection, indem die Markierungs- und Bereinigungsphasen der Garbage-Collection parallel zur Anwendungsausführung stattfinden. Diese Richtliniehat geringfügige Leistungseinbußen beim Gesamtdurchsatz zur Folge.
- Die Richtlinie "subpool" erhöht die Leistung auf Multiprozessorsystemen, in denen gewöhnlich mehr als acht Prozessoren verwendet werden. Diese Richtlinie ist nur für Prozessoren des Typs IBM System i System p und System z verfügbar. Die Richtlinie "subpool" gleicht der Richtlinie "gencon", allerdings wird der Heapspeicher in Speicherteilbereiche unterteilt, die eine bessere Skalierbarkeit für die Objektzuordnung bieten.
Information Wert Standardwert gencon Empfohlene Einstellung gencon Syntax Xgcpolicy:gencon legt für die Garbage-Collection die Richtlinie "gencon" fest. Wenn Sie gcpolicy auf gencon setzen, wird die Parallelitätsmarkierung inaktiviert. Die besten Ergebnisse beim Durchsatz werden Sie in der Regel bei Verwendung der Richtlinie "gencon" erzielen, es sei den, Sie stellen schwankende Antwortzeiten der Anwendung fest, was darauf hinweist, dass Probleme aufgrund von Wartezeiten vorliegen.
Wenn Sie gcpolicy auf optavgpause setzen, wird die Parallelitätsmarkierung mit ihren Standardwerten aktiviert. Mit dieser Einstellung können die Auswirkungen schwankender Antwortzeiten der Anwendung, die durch normale Garbage-Collections verursacht werden, gemildert werden. Diese Option wirkt sich jedoch negativ auf den Gesamtdurchsatz aus.
- -Xnoclassgc
Standardmäßig entlädt die JVM eine Klasse aus dem Speicher, wenn keine Live-Instanzen dieser Klasse mehr vorhanden sind. Der Aufwand für das wiederholte Laden und Entladen derselben Klasse kann sich nachteilig auf die Leistung auswirken.
Fehler vermeiden: Sie können das Argument -Xnoclassgc verwenden, um die Garbage-Collection für Klassen zu inaktivieren. 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.
Wenn Sie diese Option bei der erneuten Implementierung einer Anwendung verwenden, müssen Sie den Anwendungsserver immer erneut starten, damit die Klassen und statischen Daten der vorherigen Version der Anwendung bereinigt werden.
gotchaInformation Wert Standardwert Die Garbage-Collection für Klassen ist aktiviert. Empfohlene Einstellung Klassen-Garbage-Collection nicht inaktivieren.
Syntax Geben Sie Xnoclassgc an, um die Garbage-Collection nach Klassen zu inaktivieren.
- -Xgcpolicy
- Caching für den Namen des lokalen Host aktivieren Standardmäßig wird im
IBM SDK
for Java das Ergebnis der statischen Methode
java/net/InetAddress.getLocalHost nicht zwischengespeichert. Diese Methode wird
überall in WebSphere Application
Server verwendet, insbesondere jedoch in Verwaltungsagenten wie dem Deployment Manager und dem Node Agent.
Wenn sich die Adresse des lokalen Host eines Prozesses während der Ausführung nicht ändert, wird der Prozess
angewiesen, einen integrierten Cache für zum Ermitteln des lokalen Host (localhost Lookup) zu verwenden, indem die Systemeigenschaft
com.ibm.cacheLocalHost auf den Wert "true" gesetzt wird.
Anweisungen zum Festlegen der angepassten JVM-Eigenschaften für die unterschiedlichen Prozesstypen finden Sie im Artikel
zu den angepassten JVM-Eigenschaften (Java Virtual Machine).
Fehler vermeiden: Die Adresse für Server, die über DHCP konfiguriert sind, kann sich im Lauf der Zeit ändern. Daher sollte diese Eigenschaft nur festgelegt werden, wenn Sie für Ihre Server statisch zugeordnete IP-Adressen verwenden.gotcha
Information Wert Standardwert com.ibm.cacheLocalHost = false Empfohlene Einstellung com.ibm.cacheLocalHost = true (siehe Beschreibung) Verwendung Bei Angabe von -Dcom.ibm.cacheLocalHost=true wird der getLocalHost-Cache aktiviert - Aktivieren Sie die gemeinsame Nutzung von Klassen in einem Cache.
Die Option für die gemeinsame Nutzung von Klassen ermöglicht 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.
Diese Option ist standardmäßig im Anwendungsserver aktiviert. Zum Löschen des Cacheinhalts rufen Sie das Dienstprogramm "Stammverzeichnis_des_Anwendungsservers/bin/clearClassCache" auf oder stoppen Sie den Anwendungsserver und starten ihn anschließend erneut.
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 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.Falls Sie die Option für die gemeinsame Nutzung von Klassen für einen Prozess inaktivieren möchten, geben Sie für den betreffenden Prozess das generische JVM-Argument -Xshareclasses:none an:
- Klicken Sie in der Administrationskonsole auf Server>Servertypen>WebSphere-Anwendungsserver> Servername.
Klicken Sie im Abschnitt "Serverinfrastruktur" auf Java- und Prozessverwaltung > Prozessdefinition > Java Virtual Machine.
Klicken Sie im Abschnitt "Serverinfrastruktur" auf Java- und Prozessverwaltung > Prozessdefinition.
Wählen Sie Steuerung oder Servant aus und wählen Sie anschließend Java Virtual Machine aus.
- Geben Sie -Xshareclasses:none im Feld Generische JVM-Argumente ein.
- Klicken Sie auf OK.
- Klicken Sie auf Speichern, um Ihre Änderungen in der Masterkonfiguration zu speichern.
- Stoppen Sie den Anwendungsserver und starten Sie ihn dann erneut.
Information Wert Standardwert Die Option "Klassen in einem Cache gemeinsam nutzen" ist aktiviert. Empfohlene Einstellung Lassen Sie die Option "Klassen in einem Cache gemeinsam nutzen" aktiviert. Syntax -Xshareclasses:none inaktiviert die Option "Klassen in einem Cache gemeinsam nutzen". Aktivieren Sie komprimierte Referenzen in 64-Bit-Umgebungen.
Sie können komprimierte Referenzen in 64-Bit-Umgebungen wie AIX 64, Linux PPC 64, zLinux 64 und Microsoft Windows AMD64, Linux AMD64 aktivieren.
Sie können komprimierte Referenzen auch in 64-Bit-Umgebungen von IBM i, wie z. B. IBM i Version 6.1, aktivieren.
Mit der Option für komprimierte Referenzen der IBM Implementierung der 64-Bit-Version von Java SE Runtime Environment (JRE) Version 6.0 können Sie alle Speicherreferenzen auf die 32-Bit-Größe beschränken. Gewöhnlich belegen 64-Bit-JVMs mehr Heapspeicher als die 32-Bit-JVMs, weil sie 64-Bit-weite Speicherreferenzen für die Speicheradressierung verwenden. Der Heapspeicher, der über 64-Bit-Referenzen adressierbar ist, ist wesentlich größer als ein 32-Bit-Heapspeicher, aber in Wirklichkeit sind Heapspeicher, die wirklich 64 Bit für die Adressierung benötigen, gewöhnlich nicht erforderlich. Durch die Komprimierung der Referenzen wird die Größe der Adressen verringert und der Heapspeicher effizienter genutzt. Außerdem kann durch die Komprimierung dieser Referenzen die Auslastung des Prozessorcaches und des Busses verbessert werden, was wiederum eine Leistungssteigerung zur Folge hat.
Fehler vermeiden: gotcha
Das Feature für komprimierte Referenzen wird unter den folgenden Systemen nicht unterstützt:- 64-Bit-JVM unter HP-UX
- Klassische 64-Bit-JVM unter iSeries
Wenn die 64-Bit-JVM im Modus für komprimierte Referenzen ausgeführt werden soll, müssen Sie in der Konfiguration von WebSphere Application Server eine neue Umgebungsvariable angeben. Führen Sie in der Administrationskonsole die folgenden Schritte aus:
- Klicken Sie auf Server > Servertypen > WebSphere-Anwendungsserver > Servername.
- Klicken Sie auf das Register "Konfiguration". Klicken Sie anschließend unter "Serverinfrastruktur" auf Java- und Prozessverwaltung > Prozessdefinition > Servant.
- Klicken Sie unter "Weitere Eigenschaften" auf Umgebungseinträge.Gehen Sie wie folgt vor, um den Umgebungseintrag für IBM_JAVA_OPTIONS hinzuzufügen oder zu aktualisieren:
- Wenn ein Umgebungseintrag mit dem Namen IBM_JAVA_OPTIONS vorhanden ist, editieren Sie den Eintrag und hängen Sie die Java-Option "–Xcompressedrefs" an den vorhandenen Wert an.
- Ist das nicht der Fall, klicken Sie auf Neu, um einen neuen Umgebungseintrag zu erstellen.
Tragen Sie die folgenden Werte in den entsprechenden Feldern des Formulars ein:
Information Wert Name: IBM_JAVA_OPTIONS Wert: -Xcompressedrefs Beschreibung: 64-Bit-Modus für komprimierte Referenzen aktivieren
Mit dieser Prozedur wird die Datei was.env im Konfigurationsverzeichnis von WebSphereApplication Server aktualisiert. Durch die Änderung werden die Einstellungen auf alle Servant-Regionen, Steuerregionen und zusätzlichen Regionen angewendet.
Fehler vermeiden: Wenn Sie Xcompressedrefs als generisches JVM-Argument angeben, wird eine Fehlermeldung aufgrund einer nicht unterstützten Java-Option ausgegeben, und WebSphere Application Server kann nicht gestartet werden. Benötigt die Anwendung mehr als 30 GB Java-Heapspeicher, sollte der 64-Bit-Standardmodus verwendet werden.gotcha
Das Produkt aktiviert die Zeigerkomprimierung auf den unterstützten Plattformen standardmäßig, wenn die definierte Größe des Heapspeichers (die mit dem Parameter -Xmx gesteuert wird) unter einem bestimmten Wert liegt (je nach Plattform ungefähr 25 GB). Andernfalls werden standardmäßig nicht komprimierte Referenzen verwendet. Der Benutzer kann diese Standardwerte mithilfe der folgenden Befehlszeilenoptionen überschreiben.
Anmerkung: In WebSphere Application Server for z/OS ist die Zeigerkomprimierung nicht automatisch aktiviert. Die Benutzer sollten die Zeigekomprimierung manuell über Befehlszeilenoptionen aktivieren.
Anmerkung: Für Java 8 SR2 FP10 und für z/OS Java 8 SR3 wird die Option -Xcompressedrefs standardmäßig mit bis 57 GB aktiviert und kann je nach Plattform auch mit höheren Werten verwendet werden.Die folgenden Befehlszeilenoptionen steuern das Feature für komprimierte Referenzen:- -Xcompressedrefs
- Diese Befehlszeilenoption aktiviert das Feature für komprimierte Referenzen. Wenn die JVM mit dieser Befehlszeilenoption gestartet wird, werden für die Adressierung des Heapspeichers 32-Bit-weite Speicherreferenzen verwendet. Dieses Feature kann bis zu einer bestimmen Heapspeichergröße verwendet werden (ca. 29 GB je nach Plattform) die mit dem Parameter "-Xmx" gesteuert wird.
- -Xnocompressedrefs
- Diese Befehlszeilenoption inaktiviert das Feature für komprimierte Referenzen explizit. Wenn die JVM mit dieser Befehlszeilenoption gestartet wird, werden die vollständigen 64-Bit-weiten Speicherreferenzen für die Adressierung des Heapspeichers verwendet. Sie können diese Option verwenden, um die standardmäßige Aktivierung der Zeigerkomprimierung bei Bedarf außer Kraft zu setzen.
- Optimieren Sie die Konfigurationsaktualisierungsprozess für große Zellenonfigurationen. In einer großen Zellenkonfiguration müssen Sie möglicherweise abwägen, ob die Leistung der Konfigurationsaktualisierung oder eine Konsistenzprüfung wichtiger ist. Der Deployment Manager verwaltet ein Masterkonfigurationsrepository für die gesamte Zelle. Wenn sich die Konfiguration ändert, vergleicht das Produkt standardmäßig die Konfiguration im Arbeitsbereich mit dem Masterrepository, um die Arbeitsbereichskonsistenz zu gewährleisten. Der Konsistenzprüfprozess kann jedoch die Zeit für das Speichern einer Konfigurationsänderung oder für die Implementierung sehr vieler Anwendungen erhöhen. Die folgenden Faktoren haben Einfluss auf die benötigte Zeit:
- Je mehr Anwendungsserver oder Cluster in einer Zelle definiert sind, desto länger dauert die Speicherung einer Konfigurationsänderung.
- Je mehr Anwendungen in einer Zelle implementiert sind, desto länger dauert die Speicherung einer Konfigurationsänderung.
Wenn die für die Speicherung einer Konfigurationsänderung erforderliche Zeit nicht vertretbar ist, können Sie Ihren JVM-Einstellungen der angepassten Eigenschaft config_consistency_check mit dem Wert "false" hinzufügen.- Klicken Sie in der Administrationskonsole auf Systemverwaltung > Deployment Manager.
- Wählen Sie im Bereich "Serverinfrastruktur" die Option "Java- und Prozessverwaltung" aus und klicken Sie auf Prozessdefinition.
- Klicken Sie unter "Weitere Eigenschaften" auf Java Virtual Machine > Angepasste Eigenschaften > Neu.
- Geben Sie config_consistency_check im Feld "Name" und false im Feld "Wert" ein.
- Klicken Sie auf OK und speichern Sie die Änderungen anschließend in der Masterkonfiguration.
- Starten Sie den Server erneut.
Unterstützte Konfigurationen: Die angepasste Eigenschaft config_consistency_check wirkt sich nur auf den Deployment-Manager-Prozess aus. Sie hat keine Auswirkungen auf andere Prozesse, wie z. B. Node-Agent- oder Anwendungsserverprozesse. Die Konsistenzprüfung wird in diesen Prozessen nicht durchgeführt. In den Dateien SystemOut.log für diese Prozesse sehen Sie jedoch unter Umständen einen Hinweis darauf, dass die Konsistenzprüfung inaktiviert wurde. Für diese Prozesse, die keine Deployment-Manager-Prozesse sind, können Sie diese Nachricht ignorieren.sptcfg
Wenn Sie den wsadmin-Befehl wsadmin -conntype none im lokalen Modus verwenden, müssen Sie die Eigenschaft config_consistency_check auf false setzen, bevor Sie diesen Befehl ausführen.
Nächste Schritte


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tprf_tunejvm_v61
Dateiname:tprf_tunejvm_v61.html