Speicherkonfiguration des Warteschlangenmanagers

Gemeinsamer Speicher

Darüber hinaus erfordert jede gleichzeitige logische Verbindung zum Warteschlangenmanager ca. 5 KB ECSA. Wenn eine Task beendet wird, können andere IBM MQ -Tasks diesen Speicher wiederverwenden.

Sie können einen Grenzwert für den gemeinsamen Speicher, der von logischen Verbindungen zum WS-Manager verwendet wird, mit dem Konfigurationsparameter ACELIM festlegen. Die ACELIM -Steuerung ist in erster Linie für Sites von Interesse, auf denen gespeicherte Db2 -Prozeduren Operationen in IBM MQ -Warteschlangen verursachen.

Bei der Ausführung über eine gespeicherte Prozedur kann jede IBM MQ -Operation zu einer neuen logischen Verbindung zum Warteschlangenmanager führen. Große Db2 -Arbeitseinheiten, z. B. aufgrund von Tabellenlast, können zu einem übermäßigen Bedarf an gemeinsamem Speicher führen.

ACELIM soll die Nutzung des gemeinsamen Speichers begrenzen und das z/OS -System schützen, indem die Anzahl der Verbindungen im System begrenzt wird. Sie sollten ACELIM nur für Warteschlangenmanager festlegen, für die festgestellt wurde, dass sie übermäßig viel ECSA-Speicher verwenden. Weitere Informationen hierzu finden Sie im Abschnitt ACELIM unter CSQ6SYSP .

Um einen Wert für ACELIMfestzulegen, ermitteln Sie zunächst die Speichermenge, die sich momentan in dem Subpool befindet, der durch den Wert ACELIM gesteuert wird. Diese Informationen werden in den SMF 115-Sätzen des Subtyps 5, die von statistics CLASS (3) erstellt wurden, angezeigt.

IBM MQSMF-Daten können formatiert werden mitSupportPacMP1B . Die Anzahl der Byte, die im Subpool verwendet werden, der von ACELIM gesteuert wird, wird in der STGPOOL DD in der Zeile mit dem Titel ACE/PEBangezeigt.

Weitere Informationen zu SMF 115 -Statistikdatensätzen finden Sie unter IBM MQ for z/OS -Leistungsstatistik interpretieren.

Erhöhen Sie den Normalwert um eine ausreichende Marge, um Platz für Wachstum und Workloadspitzen zu schaffen. Dividieren Sie den neuen Wert durch 1024, um eine maximale Speichergröße in KB für die Verwendung in der ACELIM -Konfiguration zu erhalten.

Privater Speicher

Der Adressraum des Warteschlangenmanagers verwendet 64-Bit-Speicher für viele interne Steuerblöcke. Der Parameter MEMLIMIT der JCL des Warteschlangenmanagers definiert die maximale Größe des verfügbaren 64-Bit-Speichers. 3GB Speicher, MEMLIMIT=3G, ist das Minimum, das Sie verwenden sollten. Abhängig von Ihrer Konfiguration sind jedoch möglicherweise wesentlich mehr erforderlich.

Sie sollten einen bestimmten MEMLIMIT -Wert anstelle von MEMLIMIT=NOLIMIT angeben, um potenzielle Probleme zu vermeiden. Wenn Sie NOLIMIT oder einen sehr hohen Wert angeben, besteht die Möglichkeit, den gesamten verfügbaren virtuellen z/OS -Speicher zu nutzen, was zum Paging in Ihrem System führt. Wenn Sie den Wert von MEMLIMIT erhöhen, sollten Sie die neue Einstellung mit Ihrem z/OS -Systemprogrammierer besprechen, falls es eine systemweite Begrenzung für die Menge an verwendbarem Speicher gibt.

Wenn Sie einen großen Wert für MEMLIMIT haben, müssen Sie möglicherweise die Größe Ihrer Speicherauszugsdateien erhöhen, da mehr Daten in einem Speicherauszug erfasst werden.

Sie können die Speicherbelegung des Adressraums mithilfe der Nachricht CSQY220I überwachen, die die Menge des verwendeten privaten 31-und 64-Bit-Speichers sowie die verbleibende freie Menge angibt.

Pufferpools sind ein wichtiger Benutzer des privaten Speichers im Adressraum des Warteschlangenmanagers. Jede Pufferpoolgröße wird bei der Initialisierung des Warteschlangenmanagers bestimmt, und Speicher wird für den Pufferpool zugeordnet, wenn eine Seitengruppe, die diesen Pufferpool verwendet, verbunden ist. Der Parameter LOCATION (ABOVE|BELOW) wird verwendet, um anzugeben, wo die Puffer zugeordnet werden. Sie können den Befehl ALTER BUFFPOOL verwenden, um die Größe von Pufferpools dynamisch zu ändern.

Bei der Berechnung eines Werts für MEMLIMIT ist es wichtig, dass Sie die Pufferpoolgrößen berücksichtigen, wenn sie mit LOCATION(ABOVE)konfiguriert sind. Sie sollten die Berechnung wie folgt vornehmen:

Berechnen Sie den Wert von MEMLIMIT als 2GB plus die Größe der Pufferpools, die mit LOCATION(ABOVE)konfiguriert sind, aufgerundet auf die nächsten GB. Setzen Sie MEMLIMIT auf mindestens 3GB und erhöhen Sie diesen Wert nach Bedarf, wenn Sie die Größe Ihrer Pufferpools erhöhen müssen.

Beispiel: Für drei Pufferpools, die mit LOCATION(ABOVE)konfiguriert sind, verfügt der Pufferpool 1 über 10.000 Puffer und die Pufferpools 2 und 3 über je 50.000 Puffer. Die Speicherbelegung über dem Balken entspricht 110.000 (Gesamtzahl Puffer) * 4096 = 450.560.000 Byte = 430MB.

Alle Pufferpools verwenden unabhängig von LOCATION 64-Bit-Speicher für Steuerstrukturen. Da die Anzahl der Pufferpools und die Anzahl der Puffer in diesen Pools zunehmen, kann dies zu einer signifikanten Zunahme führen. Jeder Puffer benötigt ungefähr weitere 200 Byte 64-Bit-Speicher. Für die vorherige Konfiguration: 200 * 110.000 = 22.000.000 Byte = 21MB.

Daher können in diesem Szenario 3GB für MEMLIMITverwendet werden, was einen Bereich für Wachstum ermöglicht: 21MB + 430MB + 2GB , was auf 3GBaufgerundet wird.

Bei einigen Konfigurationen kann es erhebliche Leistungsvorteile für die Verwendung von Pufferpools geben, deren Puffer permanent durch Realspeicher gesichert werden. Dies erreichen Sie durch Angabe des Werts FIXED4KB für das Attribut PAGECLAS des Pufferpools. Sie sollten dies jedoch nur tun, wenn auf der LPAR genügend Realspeicher zur Verfügung steht, da andernfalls andere Adressräume betroffen sein könnten. Informationen dazu, wann Sie dasFIXED4KB Wert fürPAGECLAS , sehenIBM MQ Unterstützen Sie PacMP16:IBM MQ for z/OS - Kapazitätsplanung und -optimierung .

Wenn die Pufferpools so groß werden, dass ein MVS -Paging vorhanden ist, kann sich die Leistung negativ auswirken. Es kann sinnvoll sein, einen kleineren Pufferpool zu verwenden, der keine Seite enthält, wobei IBM MQ die Nachricht in die Seitengruppe und aus der Seitengruppe verschiebt.

Unter z/OSwerden lokale Warteschlangen indexiert, wenn die Warteschlange ein Attribut INDXTYPE hat, das nicht auf NONEgesetzt wurde. Die Indizes für gemeinsam genutzte Warteschlangen werden in einer Coupling-Facility gehalten, bei privaten Warteschlangen jedoch im 64-Bit-Speicher. Für jede Nachricht in einer indexierten Warteschlange werden 136 Byte an Daten zum Indexieren der Nachricht verwendet. Bei sehr tiefen Warteschlangen kann dies dazu führen, dass eine erhebliche Menge an 64-Bit-Speicher zugeordnet wird. Beispiel: 10 Millionen Nachrichten in einer indexierten Warteschlange verwenden 1.27 GB 64-Bit-Speicher, um den Index zu verwalten.

Wenn Sie eine große Anzahl von Nachrichten in indexierten Warteschlangen erwarten, sollten Sie dies berücksichtigen, wenn Sie MEMLIMITfestlegen. Um eine Obergrenze für die für Indizes erforderliche Speichermenge zu berechnen, multiplizieren Sie das Attribut MAXDEPTH für jede indexierte Warteschlange mit 136 und summieren Sie den Wert. Dieser Wert sollte Ihrer vorhandenen MEMLIMIThinzugefügt werden.

CFSTRUCT WIEDERHERSTELLEN

Ab IBM MQ 9.4.0 verwendet der Befehl RECOVER CFSTRUCT mehr 64-Bit-Speicher. In vielen Fällen sollte zusätzlicher 64-Bit-Speicher verfügbar sein. Daher erfordert die Verwendung des Befehls keine Erhöhung des Werts von MEMLIMIT. Wenn Sie jedoch wahrscheinlich umfangreiche Struktursicherungen haben, die mehr als einige Millionen Nachrichten enthalten, sollten Sie den Wert für MEMLIMIT für alle Warteschlangenmanager erhöhen, die den Befehl RECOVER CFSTRUCT möglicherweise um 500MBverarbeiten.

Wenn Sie beispielsweise bereits MEMLIMIT=3G hatten, sollten Sie die Verwendung von MEMLIMIT=4G in Betracht ziehen, da der Parameter MEMLIMIT keine Dezimalzeichen zulässt.

Puffer für Shared Message Data Set (SMDS) und MEMLIMIT

Bei der Ausführung von Messaging-Workloads mit gemeinsam genutzten Nachrichtendateien gibt es zwei Optimierungsstufen, die durch Anpassung der Attribute DSBUFS und DSBLOCK erreicht werden.

Der von dem SMDS-Puffer belegte Speicher des Warteschlangenmanagers über 2 GB ist DSBUFS x DSBLOCK. Dies bedeutet, dass standardmäßig 100 x 256KB (25MB) für jede CFLEVEL (5) -Struktur im Warteschlangenmanager verwendet wird.

Obwohl dieser Wert nicht zu hoch ist, können einige von ihnen, wenn Ihr Unternehmen oder Unternehmen über viele CFSTRUCTs verfügen, einen hohen Wert für MEMLIMIT für Pufferpools zuordnen, und manchmal verfügen sie über tief indexierte Warteschlangen, sodass ihnen insgesamt nicht mehr genügend Speicher oberhalb der Grenze zur Verfügung steht.