Publish/Subscribe-Leistungsoptimierung

Optimieren Sie Ihre Broker und die von ihnen verwendeten Datenbanken dahingehend, dass sie eine große Anzahl an Abonnements handhaben können.

WebSphere Event Broker unterstützt bis zu 25.000 Abonnements auf einem Broker. In den folgenden Abschnitten werden einige mögliche Maßnahmen beschrieben, wie Broker und Datenbanken optimiert werden können, um eine effiziente Bearbeitung dieser Abonnements zu gewährleisten.

Broker

Ändern Sie die Brokereigenschaft jvmMaxHeapSize. Der Standardwert für diese Eigenschaft ist 128 MB.

Der Wert dieser Eigenschaft muss groß genug für alle Themen in den Abonnements sein. Wenn Sie beispielsweise 10.000 Abonnements für alle Themen haben, von denen jedes 20 KB Speicher in Anspruch nimmt, müssen Sie den Wert der Eigenschaft jvmMaxHeapSize auf mindestens 200 MB setzen.

Erhöhen Sie mit dem Befehl mqsichangeproperties den Wert der Eigenschaft jvmMaxHeapSize auf 256 MB:
mqsichangeproperties brokername -o ComIbmJVMManager -n jvmMaxHeapSize -v 268435456
Dabei ist brokername der Name des Brokers.

Der Konfigurationsmanager verwendet die Liste der Abonnements, die möglicherweise auf der lokalen Festplatte gespeichert werden:

Das Verzeichnis muss mindestens zweimal größer als der Themaspeicherplatz sein; d. h. bei 10.000 Abonnements, von denen jedes 20 KB benötigt, sollte das Verzeichnis mindestens 512 MB aufweisen.

Datenbanken

Der Broker speichert Abonnementinformationen in der eigenen Datenbank. Sie müssen unter Umständen an Ihrer Datenbank Optimierungen vornehmen, um die Höchstzahl von 25.000 Abonnements bearbeiten zu können.
  • Windows platformUNIX platformLinux platform Bei Verwendung von DB2 müssen zwei Grenzwerte beachtet werden. Beide beziehen sich darauf, ob der Broker erfolgreich neu gestartet werden kann.
    • Der erste Grenzwert tritt bei ungefähr 1000 Abonnements auf. Für den DB2-Parameter APP_CTL_HEAP_SZ muss ein hoher Wert festgelegt werden, damit der Broker seine Datenbank beim Start abfragen kann. Ein Wert von 8192 ist in der Regel ausreichend für 1000 Abonnements. Der Wert kann durch Starten einer db2-Eingabeaufforderung und durch Ausgeben des Befehls db2 update db cfg using APP_CTL_HEAP_SZ 8192 geändert werden. Sie müssen dann möglicherweise Verbindungen zur Datenbank beenden.
    • Der zweite Grenzwert tritt bei ungefähr 8000 Abonnements auf. Wenn der Broker einen Startversuch unternimmt, wird der folgende Fehler möglicherweise im Systemprotokoll dokumentiert:
      Database error: SQL State '54028' (Datenbankfehler: SQL-Status '54028');
      Native Error Code '-429' (Nativer Fehlercode '-429');
      Error Text (Fehlertext) '[IBM][CLI Driver][DB2/LINUX] SQL0429N  The maximum number of concurrent LOB locators has been exceeded (Die maximale Anzahl an gleichzeitigen LOB-Querverweisen wurde überschritten). SQLSTATE=54028 '.   
      Dieser Fehler ist darauf zurückzuführen, dass die Anzahl der LOB-Kennungen in DB2 begrenzt ist. Um dieses Problem zu lösen, ist eine Programmkorrektur in DB2 erforderlich. Die Datei db2cli.ini. muss bearbeitet werden.

      Linux platformUNIX platform Auf Linux- und UNIX-Systemen befindet sich diese Datei im Verzeichnis {DB2InstanceHome}/sqllib/cfg/db2cli.ini.

      Windows platform Auf Windows-Systemen befindet sich diese Datei im Verzeichnis C:\Program Files\IBM\SQLLIB\db2cli.ini.

      Fügen Sie der Datei folgende Zeile hinzu:

      [{Datenbankname}]
      PATCH2=50
       LobCacheSize=1048576      
      In der PATCH-Zeile wird DB2 angewiesen, LOB-Querverweise nach ihrer Verwendung wieder freizugeben. Über den Parameter LobCacheSize wird der gesamte für LOB-Querverweise verfügbare Speicher angepasst; in diesem Fall handelt es sich um 1 GB. Möglicherweise muss die DB2-Instanz erneut gestartet werden.
  • z/OS platform Wenn Sie unter z/OS DB2 Version 8 verwenden, tritt bei ungefähr 15.000 Abonnements eine Datenbankbegrenzung ein. Um dies zu umgehen, muss der Wert von NUMLKUS geändert werden. Der Wert 20000 reicht für ungefähr 25.000 Abonnements.

Brokerverbünde

Wenn bei einem Broker, der Mitglied eines Verbunds oder direkt mit einem anderen Broker verbunden ist, ein Abonnement vorgenommen wird, erzeugen sämtliche Broker, die mit ihm verbunden sind, ein Proxy-Abonnement. Die Gesamtzahl an Proxy-Abonnements und direkten Abonnements muss weniger als 25.000 für jeden Broker betragen. Dieser Grenzwert wirkt sich auf die Planung der Brokertopologie aus.

Beispiel: Gehen Sie von einem Brokerverbund mit N Brokern aus.

Um die Konnektivität zu maximieren, verbinden Sie eine Instanz eines Clients mit jedem Broker, wobei jede dieser Instanzen das gleiche eindeutig Thema abonniert. Daher verfügt bei N Brokern jedes eindeutige Thema über N Clients.

In dieser Situation weist jeder Broker ein Abonnement für jeden verbundenen Client auf sowie ein Proxy-Abonnement für jeden der anderen Broker im Brokerverbund.

Somit weist jeder Broker N Abonnements für jedes eindeutige Thema auf (eins für den Client, der direkt verbunden ist, und N-1 für die Proxy-Abonnements für alle anderen Broker). Wenn T eindeutige Themen vorhanden sind, stellen Sie Folgendes sicher: N*T <= 25.000. Das heißt, wenn Sie 1000 eindeutige Themen haben, sollte der Brokerverbund auf maximal 25 Broker eingeschränkt werden.

Zugehörige Tasks
Broker modifizieren
Brokerdatenbanken konfigurieren
Zugehörige Verweise
JVM-Parameterwerte
Bemerkungen | Marken | Downloads | Bibliothek | Unterstützung | Feedback

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009. Alle Rechte vorbehalten.
Letzte Aktualisierung : 2009-02-17 15:50:04

aq20816_