CSA: Anwendungsserver, Cluster, Multicast-Messaging und Lastenausgleich (nur On-Premise)

ccppmop1581
Richten Sie Multicast-Messaging, Lastenausgleich und dauerhafte Sitzungen (allgemeingültige Sitzungen) ein. Verwenden Sie CSA zur Skalierung, Freigabe von Datenträgern, Verteilen von Dateien auf Servern und Verwaltung mehrerer Instanzen für Anwendungs- oder Hintergrunddienste. Sie können auch dedizierte Berichtsdatenbanken konfigurieren, Oracle-Datenbank-Cluster ausführen und Sun HotSpot-JVMs optimieren.
2
Skalieren von
Classic PPM
Der Begriff
Skalierung
beschreibt die komplexe Entscheidungsfindung, welche Dienste und Computer ausgeführt werden sollen. Bei einer Skalierung nach oben oder unten, sollte die Performance zuverlässig ausgeglichen sein. Selbst in kleinsten Installationen von
Classic PPM
sind mehrere Computer involviert. Zum Beispiel hat eine Installation in der Regel die folgende Konfiguration:
  • Einen Server für die Datenbank und einen anderen Server für alle anderen Aufgaben oder
  • Ein Computer für
    Classic PPM
    , der eine Verbindung zu einem Datencenter herstellt, das einer Gruppe angehört, die die Datenbank extern verwaltet.
Mittlere bis große
Classic PPM
-Installationen verwenden abhängig von den Anforderungen an Leistung und Zuverlässigkeit üblicherweise redundante Dienste, die auf mehreren dedizierten Computern ausgeführt werden.
Multicast-Messaging
Die Verwendung von Multicast-Messaging in Clustern ist in
Classic PPM
weit verbreitet. Der Beacon-Dienst ist ein Bootstrapping-Dienst, der auf allen verwalteten Computern in einem Cluster ausgeführt wird. Der Beacon-Dienst wird verwendet, um die
Classic PPM
-Dienste in den einzelnen Feldern zu verwalten und zu überwachen. Der Beacon-Dienst wird auch für die Anwendung von Patches und Upgrades verwendet, die vom
Classic PPM
-Anwendungsserver bereitgestellt werden.
Für Beacon-Dienste wird ein dynamischer Ermittlungsmechanismus eingesetzt, der Multicast verwendet. Jedes Beacon sendet alle 5 Sekunden eine Discovery-Nachricht, die jedem Listening-Server im Cluster sein Vorhandensein mitteilt. Die
Classic PPM
-Systemverwaltung lauscht nach diesen Beacon-Ermittlungsmeldungen und verwendet sie zum Registrieren der aktiven Cluster-Knoten. Nach Erhalt einer Beacon-Ermittlungsmeldung vergleicht die
Classic PPM
-Systemverwaltung das Beacon-Kennwort mit dem eigenen Kennwort. Bei einer erfolgreichen Verifizierung fügt die
Classic PPM
-Systemverwaltung den Server zur Serverliste hinzu.
Darüber hinaus sendet die
Classic PPM
-Systemverwaltung alle zehn (10) Sekunden einen direkten Ping an jedes Beacon, um zu ermitteln, ob es aktiv ist. Ein Ping ist eine TCP-Meldung (Unicast), sodass für jedes registrierte Beacon eine Nachricht über das Netzwerk gesendet wird. Der Vorteil von Multicast liegt darin, dass eine Multicast-Nachricht nur einmal über das Netzwerk gesendet, jedoch mehrfach empfangen wird. Dadurch ist UDP ressourcenschonender als TCP. Die Unicast-Nachricht muss für jeden Beteiligten eigens über das Netzwerk gesendet werden. Aus diesem Grund eignet sich Multicast ideal für dynamische Discovery- und Überwachungsanwendungen wie Beacon-Dienste.
Der Beacon-Dienst ist nicht der einzige Dienst, der Multicast verwendet. Zusätzlich zu den Beacon-Diensten senden die Cache-Verwaltungsdienste in den Anwendungs- und Hintergrundservern eigene Nachrichten, um die Cache-Konsistenz zu verwalten. Diese Meldungen enthalten keine eigentlichen Daten. Sie informieren nur Remote-Server darüber, dass vorhandene Daten veraltet sind und aus der Datenbank neu geladen werden müssen. Dieser Prozess wird als Leeren des Cache bezeichnet. Wenn ein Cache auf einem bestimmten Server in einem Cluster geleert wird, wird eine Nachricht über das Netzwerk gesendet. Alle anderen Anwendungs- und Hintergrunddienste Dienste erhalten diese Nachricht, in der sie aufgefordert werden, die eigenen Caches zu leeren.
Classic PPM
verwendet einen Sitzungsüberwachungs-Thread, um zu verhindern, dass Sitzungen auf verschiedenartigen Servern vorzeitig abgebrochen werden. Dieser Thread wird alle 5 Minuten mit einer längeren Nachricht, die aktive Sitzungs-IDs enthält, gesendet. Wenn eine Sitzung auf einem Server nicht mehr aktiv ist, wird sie auf allen Servern gelöscht. Wenn eine Sitzung weiterhin aktiv ist, wird sie auf allen anderen Servern entsprechend gekennzeichnet, damit der Benutzer nicht abgemeldet wird.
Die Server in einem
Classic PPM
-Cluster müssen in der Lage sein, Multicast-Nachrichten zu senden und zu empfangen. In einem normalen Unternetzwerk ist dies standardmäßig zugelassen.
Alle Server sollten sich im selben Unternetzwerk befinden. Wenn Sie Server an verschiedenen Standorten mit unterschiedlichen Unternetzwerken verwenden müssen, erstellen Sie eine Multicast-Bridge zwischen den Servern.
Diese Vorgehensweise kann scheinbar zusätzlichen UDP-Datenverkehr verursachen. Im Vergleich zur Datenmenge, die zwischen der Datenbank, dem Berichtsserver, den Anwendungsservern und den Clients übertragen wird, ist der Umfang des Cluster-Messaging jedoch unbedeutend. Der zusätzliche Netzwerkverkehr stellt einen geringen Prozentsatz des gesamten Datenverkehrs im Netzwerk dar. Wenn Benutzer den Begriff "Rundsenden" hören, denken sie oft, dass ihre Netzwerke überlastet sind. Tatsächlich wird der gesamte Netzwerk-Datenverkehr rundgesendet. Wie bei UDP (Multicast) kommen alle TCP-Nachrichten (Unicast) in Unternetzwerken mit jedem Knoten im Unternetzwerk in Berührung. Der Unterschied besteht darin, dass TCP-Nachrichten zwei- bis dreimal größer als UDP-Nachrichten sind. Da TCP-Nachrichten garantiert ankommen, benötigen sie mehrere Handshakes pro Paket. Dies bedeutet, dass TCP-Nachrichten größer sind. Darüber hinaus sind diese Multicast-Nachrichten in
Classic PPM
im Verhältnis zur durchschnittlichen Anforderung an die Datenbank sehr klein. Bei der Ausführung von mehreren Anwendungs-, Hintergrund- und Berichtsservern auf einem leistungsstarken System werden pro Sekunde Hunderte solcher Datenbankanfragen durchgeführt. Die kleinen UDP-Nachrichten, die alle 5 Sekunden für die Server ausgelöst werden, haben vor diesem Hintergrund keine Relevanz.
Clarity
hat JGroups in die Architektur implementiert, um Multicast-Messaging in der Anwendungsebene zu steuern. Sie konnten die Anwendungsebene ohne Multicasting bereits ausführen, aber jetzt ist sie wesentlich umfassender in die Hintergrund- und Prozess-Engine eingebunden. Diese zwei Dienste würden wahrscheinlich nicht wie erwartet durchgeführt werden.
Clarity
14.x und neuere Versionen erfordern in der Regel, dass Multicast in der Routerebene aktiviert ist, damit die
Clarity
-Cluster-Dienste ordnungsgemäß kommunizieren.
Lastenausgleich und dauerhafte Sitzungen (allgemeingültige Sitzungen)
Classic PPM
unterstützt hardware- und softwarebasierte Lastenausgleichsmodule.
Classic PPM
ist statusfrei und wurde für Round-Robin und andere Verteilungsmodelle konzipiert. Am effizientesten in Hinblick auf Arbeitsspeicher und Leistung ist es allerdings, Benutzersitzungen stets auf einem einzigen Server zu halten. Durch das Hinzufügen von mehreren Anwendungsservern können Sie die Leistung verbessern.
Sitzungsdauerhaftigkeit ist in Umgebungen mit Lastenausgleich erforderlich. Dauerhafte Sitzungen sind unabhängig vom eingesetzten Algorithmus und der Anzahl der Ressourcen auf dem Server erforderlich.
Ein Beispiel zur Veranschaulichung ist ein Lastenausgleichsalgorithmus, der einzelne Anforderungen für einzelne Benutzersitzungen auf alle fünf Anwendungsserver verteilt. In diesem Fall werden diese Benutzersitzungsdaten auf Serverebene geladen und gespeichert. Sie benötigen fünf Mal mehr Speicher als bei aktivierter Sitzungsdauerhaftigkeit, damit die Benutzersitzung auf einem einzigen Server verbleibt.
Aktivieren Sie die dauerhaften Sitzungen für den Lastenausgleich.
Konfigurieren Sie den Lastenausgleich, um intelligente dauerhafte Sitzungen zu verwenden. Bei intelligenten dauerhaften Sitzungen werden Anforderungen von derselben Benutzersitzung an denselben Server gesendet. Wenn dieser Server überlastet ist oder sich ein anderer Server im Leerlauf befindet, wird die Dauerhaftigkeit auf den verfügbaren Server verschoben.
Classic PPM
unterstützt diesen Prozess, da die Anwendung vollständig statusfrei ist. Wenn eine überlasteter Server abstürzt, sind diese Sitzungen überdies nicht verloren. Vorausgesetzt, dass das Lastenausgleichsmodul den heruntergefahrenen Server korrekt ermittelt und die Anforderungen an andere Server umleitet, sind diese Benutzersitzungen auf dem neuen Server vollständig verfügbar.
Freigeben von Datenträgern
In einem
Classic PPM
-Cluster müssen mehrere Anwendungs- und Hintergrunddienste für die Suchindizierung denselben Datenträger verwenden. Wenn die Dateien nicht in der Datenbank gespeichert sind, müssen die Dienste auch für das Speichern von Dokumenten denselben Datenträger verwenden. Stellen Sie in der
Classic PPM
-Systemverwaltung sicher, dass alle Server mit Anwendungs- oder Hintergrunddiensten in der Eigenschaft "Indexverzeichnis durchsuchen" auf denselben freigegebenen Datenträger verweisen. Wenn die Dateien nicht in der Datenbank gespeichert sind, muss die Eigenschaft "Indexverzeichnis durchsuchen" auch auf denselben freigegebenen Datenträger verweisen.
Die Storage Area Network- oder Network Attached Storage-Lösung stellt die effektivste Methode zum Freigebn von Datenträgern dar. Sie können auch die Unix NFS- oder Windows-Dateifreigabe verwenden.
Verteilen von Dateien an Server in einem Cluster
Verteilen Sie aktualisierte Dateien auf alle Server im Cluster. Aktualisierte Dateien umfassen Dateien auf dem Anwendungsserver, die über angepasste Benutzeroberflächenthemen oder Installationen von Hotfixes, Patches oder Upgrades aktualisiert werden.
Sie können auch den Status der Verteilung anzeigen, indem Sie auf die NSA-Protokolle klicken und "nsa-ca.log" auswählen. Anschließend wird das Statusfenster geschlossen, und die übergeordnete Seite wird angezeigt. Auf der Seite "Verteilung" werden Datum und Version der letzten Verteilung angezeigt.
Gehen Sie wie folgt vor:
  1. Melden Sie sich bei der
    Classic PPM
    -Systemverwaltung (CSA) an.
  2. Öffnen Sie "Verteilung", und klicken Sie auf "Alle verteilen".
    Diese Option verteilt alle aktualisierten Dateien im
    Classic PPM
    -Stammverzeichnis.
  3. Wählen Sie einen oder mehrere Server aus, und klicken Sie auf "Verteilen".
Mehrere Anwendungs- oder Hintergrunddienst-Instanzen
Wenn Sie Großrechner mit umfangreichem verfügbarem physischem Speicher verwenden, führen Sie auf diesen Computern mehrere Instanzen der Anwendungs- und Hintergrunddienste aus. Aus der Perspektive von
Classic PPM
unterscheidet sich dies nicht von der Ausführung von Diensten auf zwei separaten Computern. Sie können die volle Leistungsfähigkeit eines Computers nutzen und zugleich die Vorteile der höheren Performance und Zuverlässigkeit durch den Einsatz mehrere Dienste ausschöpfen.
Dank der Option "Klonen", die in der CSA bereitgestellt wird, ist es einfach, mehrere Instanzen zu verwenden. Über diese Aktion wird eine Kopie des gewünschten Anwendungs- oder Hintergunddienstes mit inkrementierten, verfügbaren Ports und Dienstnamen erstellt, um Konflikte zu vermeiden.
Nachdem Sie einen Dienst geklont haben, können Sie die neue Dienstinstanz genauso wie den Originaldienst starten, anhalten oder anderweitig verwalten.
Gehen Sie wie folgt vor:
  1. Melden Sie sich bei CSA an.
  2. Öffnen Sie die Startseite, und klicken Sie auf "Alle Dienste".
  3. Aktivieren Sie das Kontrollkästchen für den Diensttyp, den Sie klonen möchten, und klicken Sie auf "Klonen".
  4. Wechseln Sie bei Bedarf zum Server, auf dem Sie einen neuen Dienst erstellt haben, und ändern Sie die geklonten Einstellungen.
Konfigurieren einer dedizierten externen Datenquelle
Sie können
Classic PPM
so konfigurieren, dass Sie eine sekundäre Datenbank zum Ausführen von Berichten verwenden können. Stellen Sie sicher, dass eine sekundäre Datenbank sinnvoll mit Ihrer
Classic PPM
-Produktionsdatenbank synchronisiert ist. Wenn die Berichtsdatenbank zu weit hinter dem Stand der Produktionsdatenbank liegt, können Probleme auftreten. Wenn beispielsweise Benutzer- oder Instanzdaten, die für den Bericht relevant sind, in der Berichtsdatenbank nicht existieren.
Wenn ein Bericht entsprechend dem folgenden Verfahren konfiguriert ist, wird er nur für die Berichtsdatenbank ausgeführt. Alle Tabellen, die für die Berichte benötigt werden, einschließlich der Benutzer- und Sicherheitstabellen, müssen synchronisiert werden. Wenn Sie eine Teilmenge der Produktionsdatenbanktabellen synchronisieren möchten, wählen Sie die richtigen Tabellen aus, die Ihre Berichte unterstützen.
Gehen Sie wie folgt vor:
  1. Melden Sie sich bei CSA an, und klicken Sie unter "Startseite" auf "Server".
  2. Klicken Sie auf das Eigenschaftssymbol für den Server, den Sie konfigurieren möchten.
  3. Klicken Sie auf die Unterregisterkarte "Datenbank".
  4. Klicken Sie im Bereich "Interne Verbindung:Niku" auf "Neue externe Verbindung".
  5. Geben Sie die entsprechenden Eigenschaften für Ihre Berichtsdatenbank an:
    • ID
      Definiert die ID, mit der diese Verbindung später identifiziert wird.
    • Dienstname
      Verweist auf einen gültigen TNS-Eintrag (Oracle) oder ODBC-Eintrag (MS SQL Server) auf dem Berichtsserver.
  6. Speichern Sie die Änderungen.
  7. Klicken Sie auf die Unterregisterkarte "Berichterstellung".
  8. Füllen Sie das folgende Feld aus:
    • Datenbank-ID
      Die
      Classic PPM
      -Datenbank-ID, die beim Ausführen von Berichten zum Abrufen von Datenbankinformationen verwendet wird. Diese ID entspricht den IDs der Datenbankverbindungen, die auf der Seite
      Server: Eigenschaften
      für die Datenbank definiert sind.
      Werte:
      Niku und System
      Standard:
      Niku
      Erforderlich
      : Nein
  9. Speichern Sie die Änderungen.
  10. Wiederholen Sie diese Schritte für alle Server im
    Classic PPM
    -Cluster.
  11. Starten Sie alle
    Classic PPM
    -Anwendungsdienste (app) und
    Classic PPM
    -Hintergrunddienste (bg) im Cluster neu.
  12. Führen Sie folgende Schritte für jeden Berichtsserver im Cluster aus:
    1. Erstellen Sie einen TNS-Eintrag (Oracle) bzw. ODBC-Eintrag (SQL Server) mit entsprechenden Verbindungseigenschaften, die auf den dedizierten Berichtsdatenbankserver verweisen.
    2. Stellen Sie sicher, dass der gewählte Name mit dem Dienstnamen für die externe Verbindung in der
      Classic PPM
      -Systemverwaltung übereinstimmt.
  13. Installieren Sie den Berichtsdienst.
In Version 14.4 und älteren konnten Sie mit diesen Schritten Berichte, das
Classic PPM
-Universum und andere Berichtsinhalte auf dem BusinessObjects Enterprise-Berichtsserver installieren. In Version 15.1 und neueren Versionen könnten Sie mit diesen Schritten eine parallele Transaktionsdatenbank einrichten, um Berichte auszuführen anstatt das Data Warehouse-Schema zu verwenden oder auch beides zu tun. Die Schritte gelten für das Hinzufügen aller zusätzlichen Datenquellen zu On-Premise-Editionen von
Clarity
. Fügen Sie beispielsweise ein repliziertes Transaktionsschema, ein externes Data Warehouse oder das App-Schema eines Drittanbieters hinzu, das sich in einer Oracle- oder MS-SQL-Datenbank befindet.
Oracle-Datenbank-Cluster
Classic PPM
unterstützt die Verwendung von Oracle-Clustern, um höhere Skalierbarkeit, Redundanz und Ausfallsicherheit bereitzustellen, als mit einem einzelnen Oracle-Server möglich ist.
Gehen Sie wie folgt vor:
  1. Exportieren Sie die vorhandene Einzelserver-Oracle-Datenbank bei Bedarf aus der einzelnen Knoteninstanz, und importieren Sie sie in den Cluster.
  2. Melden Sie sich bei CSA an.
  3. Öffnen Sie die Startseite, und klicken Sie auf "Server".
  4. Klicken Sie auf das Eigenschaftensymbol für den Server, dessen Eigenschaften Sie bearbeiten möchten.
  5. Klicken Sie auf die Unterregisterkarte "Datenbank".
  6. Bearbeiten Sie die folgenden Eigenschaften für die Datenbankverbindung:
    • URL angeben
      Ausgewählt.
    • JDBC URL
      Vollständig qualifizierter JDBC URL des Oracle-Clusters. Diese URL enthält ein jdbc-Präfix, gefolgt von der vollständigen TNS-Angabe.
      Die JDBC URL muss den ServiceName-Parameter enthalten, der auf einen TNS-Eintrag auf dem angegebenen Oracle-Host mit der gewünschten RAC-Konfiguration verweist.
      Beispiel:
      jdbc:clarity:oracle://server:1521;ServiceName=serviceTNS;BatchPerformanceWorkaround=true;InsensitiveResultSetBufferSize=0;ServerType=dedicated;supportLinks=true
      Andere Beispiele:
      Betten Sie die RAC-Server mit der folgenden DataDirect-Syntax in die URL ein:
      jdbc:clarity:oracle://server1:1521;ServiceName=serviceTNS;BatchPerformanceWorkaround=true;InsensitiveResultSetBufferSize=0;ServerType=dedicated;supportLinks=true;AlternateServers=(server2:1521;server3:1521);LoadBalancing=true
      Oracle RAC-Server mit SCAN-Listener:
      jdbc:clarity:oracle://oracscan:1521;ServiceName=serviceTNS;BatchPerformanceWorkaround=true;InsensitiveResultSetBufferSize=0;ServerType=dedicated;supportLinks=true;AlternateServers=(oracscan:1521);FailoverMode=Select;ConnectionRetryCount=20;ConnectionRetryDelay=15;LoadBalancing=true"
      Oracle DataGuard:
      jdbc:clarity:oracle://PRIMARY_SERVER:1521;ServiceName=CLARITY_RW;AlternateServers=(PHYSICAL_STANDBY_SERVER:1521);ConnectionRetryCount=20;ConnectionRetryDelay=15;;BatchPerformanceWorkaround=true;InsensitiveResultSetBufferSize=0;ServerType=dedicated;supportLinks=true
      Weitere Informationen finden Sie in folgenden Ressourcen:
      Oracle-Dokumentation für die Konfiguration von RAC, DataGuard, SCAN und Diensten.
      DataDirect-Website. Suchen Sie Informationen zur Verwendung von DataDirect Connect für JDBC mit Oracle Real Application Cluster (RAC).
  7. Speichern Sie die Änderungen.
  8. Führen Sie einen Systemzustandsbericht für jeden Server aus, um die Datenbankeinstellungen zu überprüfen. Weitere Informationen finden Sie unter Ausführen eines Statusberichts.
  9. Wenn Sie Apache Tomcat-Anwendungsserver verwenden, starten Sie alle Dienste in der
    Classic PPM
    -Systemverwaltung neu.
Optimieren von Sun HotSpot JVMs
Diese Informationen gelten nur für Umgebungen mit Sun HotSpot JVMs.
Bei der Konfiguration und Verwaltung von
Classic PPM
ist es wichtig, die Sun HotSpot JVM zu optimieren. Noch wichtiger als für den Hintergrunddienst ist die richtige Optimierung für alle im Cluster ausgeführte Anwendungsdienste. Dieser Artikel konzentriert sich auf die Anwendung.
Die Dokumentation für diese Einstellungen finden Sie auf der Oracle-Website. Sie können sich auch an Broadcom-Servicepartner wenden, um Unterstützung zur Dimensionierung Ihrer JVM-Heap-Größe basierend auf Ihrer Implementierung zu erhalten.
Für das Optimieren einer HotSpot JVM sind viele Optionen verfügbar.
Best Practice:
Verwenden Sie mindestens die folgenden Werte:
  • Maximum Heap
    -Xmx<size>m
    Mithilfe der Einstellung für den maximalen Heap wird der maximale Speicher bestimmt, den das lokale Betriebssystem für die Java VM bereitstellt. Das lokale Betriebssystem weist den gesamten Speicher nicht sofort beim Starten zu, sondern später während des Prozessablaufs. Setzen Sie als Best Practice diesen Wert auf mindestens 2048m (2 GB), auch für kleine Installationen. Setzen Sie diesen Wert für eine verbesserte Leistung und weniger Out-of-Memory-Fehler auf 4 GB oder 8 GB für größere Datensätze. Zum Beispiel, -Xms1024m -Xmx4096m.
  • Minimum Heap
    -Xms<size>m
    Die Einstellung für den minimalen Heap ist wichtig, um Verschwendung durch die VM zu verhindern, wenn der Heap beim Starten der Anwendung erhöht wird. Geben Sie für den minimalen Heap einen Wert ein, der der Realität möglichst nahe kommt. Wenn die Anwendung üblicherweise 1,2 GB RAM verwendet, setzen Sie Einstellung für den minimalen Heap auf 1200m. Sie können für die Einstellungen für den minimalen Heap und den maximalen Heap den gleichen Wert festlegen. Dadurch wird der Aufwand für den VM Garbage Collector verringert. Diese Einstellungen bewirken auch, dass der JVM-Prozess den vollständigen maximalen Heap vom Betriebssystem beim Starten zuweist (konsistentere Vorgehensweise). Dieser Prozess erfordert, dass Sie die wahren Anforderungen an die Arbeitsspeicherzuordnung auf Ihrem Server messen.
  • Parallel Garbage Collector
    -XX:+UseParallelGC
    Der parallele Garbage Collector wird für alle Server mit mindestens zwei CPUs empfohlen. Die Einrichtung des parallelen Garbage Collectors ist auf allen Servern sicher. Server mit weniger als zwei CPUs ignorieren diese Einstellung.
  • New Ratio
    -XX:NewRatio=<size>
    Die HotSpot VM trennt Objekte basierend auf der Dauer der Objekte im Speicher in New Space und Old Space. Kurzlebige Objekte bleiben meistens im New Space (oder Eden Space) und werden erfasst, bevor sie weitergeleitet werden. Langlebige Objekte werden in den Old Space (oder Tenured Space) migriert. Die Einstellung für das Verhältnis von neu zu alt definiert nicht die ausdrückliche Größe des New Space, sondern das Verhältnis von Old Space zu New Space. Die Einstellung "-XX:NewRatio=3" bedeutet ein Verhältnis von 1:3, wobei die neue Generation ein Drittel der alten Generation ausmacht. Anwendungen, die in kurzer Zeit viele kurzlebige temporäre Objekte erstellen und löschen, beispielsweise serverseitige Anwendungen wie
    Classic PPM
    , benötigen überdurchschnittlich viel Speicherplatz. Andernfalls wird der New Space überlastet, während der Old Space nicht ausgelastet ist. Der Standardwert für "New Ratio" fällt je nach Plattform unterschiedlich aus. Um unabhängig von der Plattform Probleme in
    Classic PPM
    zu vermeiden, setzen Sie den Wert für "New Ratio" auf 1:2, d. h.
    XX:NewRatio=2
    .
  • Maximum Permanent Size
    -XX:MaxPermSize=<size>m
    Neben dem New Space und Old Space gibt es einen dritten Bereich, den sogenannten Permanent Space. In diesem Bereich befinden sich die permanenten Objekte, vor allem Definitionen von Java-Klassen. Dieser Bereich wird nicht mit der Verwendung der Anwendung umfangreicher, sondern aufgrund der Größe der Anwendung. Je mehr Klassen in der Anwendung geladen sind, umso größer ist die permanente Größe. Die Standardeinstellung von 64m hat sich als zu klein erwiesen. Bei Apache Tomcat ist die
    Classic PPM
    -Standardeinstellung für diesen Bereich 256 m.