Messung der Cachebelegung

WebSphere eXtreme Scale kann die Belegung des Java-Heapspeichers für eine bestimmte BackingMap in Bytes genau schätzen. Mit dieser Funktion können Sie die Einstellungen für den Heapspeicher und die Bereinigungsrichtlinien für Ihre Java Virtual Machine korrekt messen. Das Verhalten dieses Features variiert mit der Komplexität der Objekte, die in die BackingMap eingefügt werden, und der Konfiguration der Map. Derzeit wird dieses Feature nur für verteilte Datengrids unterstützt. Lokale Datengridinstanzen unterstützen die Messung belegter Bytes nicht.

Hinweise zur Heapspeicherbelegung

eXtreme Scale speichert alle Daten im Heapspeicher der JVM-Prozesse, aus denen sich das Datengrid zusammensetzt. Der belegte Heapspeicher für eine bestimmte Map kann in die folgenden Komponenten unterteilt werden:
  • Größe aller derzeit in der Map befindlichen Schlüsselobjekte
  • Größe aller derzeit in der Map befindlichen Werteobjekte
  • Größe aller EvictorData-Objekte, die von Evictor-Plug-ins in der Map verwendet werden
  • Gemeinkosten für die zugrunde liegende Datenstruktur

Die Anzahl der in den Messstatistiken berichteten belegten Bytes ist die Summe dieser vier Komponenten. Diese Werte werden auf Eintragsbasis in den Map-Operationen "insert" (Einfügen), "update" (Aktualisiere) und "remove" (Entfernen) berechnet, d. h., dass eXtreme Scale immer den aktuellen Wert für die Anzahl der Bytes hat, die eine bestimmte BackingMap belegt.

Wenn Datengrids partitioniert sind, enthält jede Partition einen Teil der BackingMap. Da die Messstatistiken auf der untersten Ebene des eXtreme-Scale-Codes berechnet werden, verfolgt jede Partition einer BackingMap ihre eigene Größe. Sie können die eXtreme Scale Statistik-APIs verwenden, um die kumulative Größe der Map sowie die Größe der einzelnen Map-Partitionen zu verfolgen.

Im Allgemeinen werden die Größendaten als Maß für den Trend der Datengröße über der Zeit und nicht als genaue Messung des von der Map belegten Heapspeichers verwendet. Wenn sich beispielsweise die berichtete Größe für eine Map von 5 MB auf 10 MB verdoppelt, können Sie davon ausgehen, dass sich die Speicherbelegung der Map verdoppelt hat. Der Ist-Messwert von 10 MB kann aus verschiedenen Gründen ungenau sein. Wenn Sie diese Gründe berücksichtigen und den bewährten Verfahren folgen, entspricht die Genauigkeit der Größenmesswerte nahezu der der Nachbearbeitung eines Java-Heapspeicherauszugs.

Das Hauptproblem mit der Genauigkeit ist darin gegründet, dass das Java-Speichermodell für garantiert genaue Speichermesswerte nicht nicht restriktiv genug ist. Das grundlegende Problem besteht darin, dass ein Objekt aufgrund mehrerer Referenzen im Heapspeicher verbleiben kann. Wird dieselbe 5-KB-Objektinstanz beispielsweise in drei verschiedene Maps eingefügt, verhindert jede dieser drei Maps die Erfassung des Objekts durch die Garbage-Collection. In dieser Situation ist jeder der folgenden Messwerte vertretbar:
  • Die Größe jeder Map erhöht sich um 5 KB.
  • Die Größe der ersten Map, in die das Objekt eingefügt wird, erhöht sich um 5 KB.
  • Die Größe der anderen beiden Maps erhöht sich nicht. Die Größe jeder Map erhöht sich um einen Anteil der Objektgröße.

Aufgrund dieser Mehrdeutigkeit sollten diese Messwerte als Trenddaten behandelt werden, sofern die Mehrdeutigkeit nicht durch Designoptionen, bewährte Verfahren und Verständnis der Implementierungsoptionen die genauere Statistiken liefern können, ausgeschaltet wird.

eXtreme Scale geht davon aus, dass eine bestimmte Map die einzige Langzeitreferenz auf Schlüssel- und Werteobjekte, die sie enthält, besitzt. Wenn dasselbe 5-KB-Objekt in drei Maps eingefügt wird, erhöht sich die Größe jeder Map um 5 KB. Die Erhöhung ist gewöhnlich kein Problem, weil das Feature nur für verteilte Datengrids unterstützt wird. Wenn Sie dasselbe Objekt in drei verschiedene Maps auf einem fernen Client einfügen, erhält jede Map eine eigene Kopie des Objekts. Die Standardtransaktionseinstellungen für den Kopiermodus (COPY MODE) garantieren gewöhnlich, dass jede Map eine eigene Kopie eines bestimmten Objekts erhält.

Objektinternalisierung

Objektinternalisierung kann beim Schätzen der Heapspeicherbelegung eine Herausforderung darstellen. Wenn Sie die Objektinternalisierung implementieren, stellt Ihr Anwendungscode sicher, dass alle Referenzen auf einen bestimmten Objektwert auf dieselbe Objektinstanz im Heapspeicher und damit auf dieselbe Position im Hauptspeicher zeigen. Die folgende Klasse dient als Beispiel:
 public class ShippingOrder implements Serializeable,Cloneable{

     public static final STATE_NEW = “new”;
     public static final STATE_PROCESSING = “processing”;
     public static final STATE_SHIPPED = “shipped”;

     private String state;
     private int orderNumber;
	private int customerNumber;

	public Object clone(){
        ShippingOrder toReturn = new ShippingOrder();
        toReturn.state = this.state;
        toReturn.orderNumber = this.orderNumber;
        toReturn.customerNumber = this.customerNumber;
        return toReturn;
     }
 
     private void readResolve(){
         if (this.state.equalsIgnoreCase(“new”)
             this.state = STATE_NEW;
         else if (this.state.equalsIgnoreCase(“processing”)
             this.state = STATE_PROCESSING;
         else if (this.state.equalsIgnoreCase(“shipped”)
             this.state = STATE_SHIPPED:
     }
 }
Objektinternalisierung führt zu überhöhten Schätzwerten in den Größenstatistiken, weil eXtreme Scale davon ausgeht, dass die Objekte verschiedene Speicherpositionen verwenden. Wenn eine Million ShippingOrder-Objekte vorhanden sind, zeigen die Größenstatistiken die Kosten für eine Million Zeichenfolgen an, die die Statusinformationen enthalten. In Wirklichkeit sind nur drei Zeichenfolgen vorhanden, die statische Klasseneinträge sind. Die Speicherkosten für statische Klasseneinträge dürfen zu keiner Map von eXtreme Scale addiert werden. Diese Situation kann zur Laufzeit jedoch nicht erkannt werden. Es gibt Dutzende von Methoden, mit denen eine ähnliches Internalisierung implementiert werden kann, und deshalb ist die Erkennung solcher Situationen so schwierig. Ein globaler Schutz vor allen potenziellen Implementierungen in eXtreme Scale ist nicht praktikabel. eXtreme Scale bietet jedoch Schutz vor den meisten gängigen Typen von Objektinternalisierung. Zum Optimieren der Speicherbelegung mit Objektinternalisierung implementieren Sie die Internalisierung nur für angepasste Objekte, die den folgenden beiden Kategorien zugeordnet sind, um die Genauigkeit der Speicherbelegungsstatistiken zu erhöhen:
  • eXtreme Scale führt eine automatische Anpassung für Java-5-Aufzählungen (Enum) und typensichere Enum-Muster durch (siehe die Beschreibung unter Java 2 Platform Standard Edition 5.0 Overview: Enums).
  • eXtreme Scale berücksichtigt automatisch die automatische Internalisierung primitiver Wrappertypen wie Integern. Die automatische Internalisierung primitiver Wrappertypen wurde in Java 5 durch die Verwendung statischer valueOf-Methoden eingeführt.

Speicherbelegungsstatistiken

Verwenden Sie eine der folgenden Methoden, um auf die Speicherbelegungsstatistiken zuzugreifen.
Statistik-API

Verwenden Sie die Methode MapStatsModule.getUsedBytes(), die Statistiken für eine einzige Map bereitstellt, einschließlich der Anzahl an Einträgen und der Trefferrate.

Einzelheiten finden Sie unter Statistikmodule.

Managed Beans (MBeans)

Verwenden Sie die MBean-Statistik "MapUsedBytes". Sie können verschiedene Typen von JMX-Beans (Java Management Extensions) verwenden, um Implementierungen zu verwalten und zu überwachen. Jede MBean bezieht sich auf eine bestimmte Entität, z. B. eine Map, eXtreme Scale, einen Server, eine Replikationsgruppe oder ein Replikationsgruppen-Member.

Einzelheiten finden Sie unter Verwaltung mit Managed Beans (MBeans).

PMI-Module (Performance Monitoring Infrastructure)

Sie können die Leistung Ihrer Anwendungen mit den PMI-Modulen überwachen. Verwenden Sie insbesondere die PMI-Module für Container, die in WebSphere Application Server integriert sind.

Einzelheiten finden Sie unter PMI-Module.

Konsole von WebSphere eXtreme Scale

Sie können die Speicherbelegungsstatistiken in der Konsole anzeigen. Einzelheiten finden Sie unter Überwachung mit der Webkonsole.

Alle beschriebenen Methoden greifen auf denselben Basismesswert für die Speicherbelegung einer bestimmten BaseMap-Instanz zu. Die Laufzeitumgebung von WebSphere eXtreme Scale versucht, die von den in der Map gespeicherten Schlüssel- und Werteobjekten belegten Bytes des Heapspeichers und die Gemeinkosten für die Map bestmöglich selbst zu berechnen. Sie können anzeigen, wie viel Heapspeicher die einzelnen Maps im gesamten verteilten Datengrid belegen.

In den meisten Fällen liegt der von WebSphere eXtreme Scale für eine bestimmte Map berichtete Wert sehr nahe bei dem Wert, der von der Heapspeicherauszugsanalyse berichtet wird. WebSphere eXtreme Scale misst seine eigenen Gemeinkosten genau, kann aber nicht jedes potenzielle Objekt berücksichtigen, dass in eine Map eingefügt wird. Durch die Einhaltung der unter Agent für die Messung der Cachegröße im Hinblick auf genaue Schätzungen der Speicherbelegung optimieren beschriebenen bewährten Verfahren kann die Genauigkeit der ermittelten Bytemesswerte von WebSphere eXtreme Scale erhöhen.